浏览器工作原理与实践
李兵
前盛大创新院高级研究员
立即订阅
6167 人已学习
课程目录
已完结 42 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 (1讲)
开篇词 | 参透了浏览器的工作原理,你就能解决80%的前端难题
免费
宏观视角下的浏览器 (6讲)
01 | Chrome架构:仅仅打开了1个页面,为什么有4个进程?
02 | TCP协议:如何保证页面文件能被完整送达浏览器?
03 | HTTP请求流程:为什么很多站点第二次打开速度会很快?
04 | 导航流程:从输入URL到页面展示,这中间发生了什么?
05 | 渲染流程(上):HTML、CSS和JavaScript,是如何变成页面的?
06 | 渲染流程(下):HTML、CSS和JavaScript,是如何变成页面的?
浏览器中的JavaScript执行机制 (5讲)
07 | 变量提升:JavaScript代码是按顺序执行的吗?
08 | 调用栈:为什么JavaScript代码会出现栈溢出?
09 | 块级作用域:var缺陷以及为什么要引入let和const?
10 | 作用域链和闭包 :代码中出现相同的变量,JavaScript引擎是如何选择的?
11 | this:从JavaScript执行上下文的视角讲清楚this
V8工作原理 (3讲)
12 | 栈空间和堆空间:数据是如何存储的?
13 | 垃圾回收:垃圾数据是如何自动回收的?
14 | 编译器和解释器:V8是如何执行一段JavaScript代码的?
浏览器中的页面循环系统 (6讲)
15 | 消息队列和事件循环:页面是怎么“活”起来的?
16 | WebAPI:setTimeout是如何实现的?
17 | WebAPI:XMLHttpRequest是怎么实现的?
18 | 宏任务和微任务:不是所有任务都是一个待遇
19 | Promise:使用Promise,告别回调函数
20 | async/await:使用同步的方式去写异步代码
浏览器中的页面 (8讲)
21 | Chrome开发者工具:利用网络面板做性能分析
22 | DOM树:JavaScript是如何影响DOM树构建的?
23 | 渲染流水线:CSS如何影响首次加载时的白屏时间?
24 | 分层和合成机制:为什么CSS动画比JavaScript高效?
25 | 页面性能:如何系统地优化页面?
26 | 虚拟DOM:虚拟DOM和实际的DOM有何不同?
27 | 渐进式网页应用(PWA):它究竟解决了Web应用的哪些问题?
28 | WebComponent:像搭积木一样构建Web应用
浏览器中的网络 (3讲)
29 | HTTP/1:HTTP性能优化
30|HTTP/2:如何提升网络速度?
31|HTTP/3:甩掉TCP、TLS 的包袱,构建高效网络
浏览器安全 (5讲)
32 | 同源策略:为什么XMLHttpRequest不能跨域请求资源?
33 | 跨站脚本攻击(XSS):为什么Cookie中有HttpOnly属性?
34 | CSRF攻击:陌生链接不要随便点
35 | 安全沙箱:页面和系统之间的隔离墙
36 | HTTPS:让数据传输更安全
结束语 (1讲)
结束语 | 大道至简
课外加餐 (4讲)
加餐一|浏览上下文组:如何计算Chrome中渲染进程的个数?
加餐二|任务调度:有了setTimeOut,为什么还要使用rAF?
加餐三|加载阶段性能:使用Audits来优化Web性能
加餐四|页面性能工具:如何使用Performance?
浏览器工作原理与实践
登录|注册

34 | CSRF攻击:陌生链接不要随便点

李兵 2019-10-22
上一篇文章中我们讲到了 XSS 攻击,XSS 的攻击方式是黑客往用户的页面中注入恶意脚本,然后再通过恶意脚本将用户页面的数据上传到黑客的服务器上,最后黑客再利用这些数据进行一些恶意操作。XSS 攻击能够带来很大的破坏性,不过另外一种类型的攻击也不容忽视,它就是我们今天要聊的 CSRF 攻击。
相信你经常能听到的一句话:“别点那个链接,小心有病毒!”点击一个链接怎么就能染上病毒了呢?
我们结合一个真实的关于 CSRF 攻击的典型案例来分析下,在 2007 年的某一天,David 无意间打开了 Gmail 邮箱中的一份邮件,并点击了该邮件中的一个链接。过了几天,David 就发现他的域名被盗了。不过几经周折,David 还是要回了他的域名,也弄清楚了他的域名之所以被盗,就是因为无意间点击的那个链接。
那 David 的域名是怎么被盗的呢?
我们结合下图来分析下 David 域名的被盗流程:
David 域名被盗流程
首先 David 发起登录 Gmail 邮箱请求,然后 Gmail 服务器返回一些登录状态给 David 的浏览器,这些信息包括了 Cookie、Session 等,这样在 David 的浏览器中,Gmail 邮箱就处于登录状态了。
接着黑客通过各种手段引诱 David 去打开他的链接,比如 hacker.com,然后在 hacker.com 页面中,黑客编写好了一个邮件过滤器,并通过 Gmail 提供的 HTTP 设置接口设置好了新的邮件过滤功能,该过滤器会将 David 所有的邮件都转发到黑客的邮箱中。
最后的事情就很简单了,因为有了 David 的邮件内容,所以黑客就可以去域名服务商那边重置 David 域名账户的密码,重置好密码之后,就可以将其转出到黑客的账户了。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《浏览器工作原理与实践》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(8)

  • 李小白
    老师,我想请问一下,在浏览器打开第三方站点是如何拿到极客时间站点cookie的?第三方站点和极客时间的站点不同,存在同源策略,所以转账请求验证cookie也是不通过的,那么CSRF是如何攻击的呢?
    2019-10-22
    4
    5
  • 許敲敲
    老师,这方面有比较好的资料或是书嘛?想多了解一下

    作者回复: 主要是根据这几年工作经验和浏览器文档、源码总结出来的,因为维护一个日活跃几千万的浏览器,能带来大量的流量,而流量就是金钱,因此我们的浏览器会遭受到各种类型的攻击,所以我们有很大一部分时间都是在处理攻击!

    当然为了写这个专栏,网上web安全相关的书籍我也买了好多,基本都看了一圈,但是有一些问题:
    第一是这些书籍都有一些年限了,里面的知识比较滞后!
    第二,大多数和前端关系不是太大
    第三,大多数写的比较零碎


    你们如果发现有好的web安全相关的书籍,也可以推荐下!

    2019-10-22
    1
    3
  • “简言之,如果你从极客时间的页面中访问 InfoQ 的资源,而 InfoQ 的某些 Cookie 设置了 SameSite = Strict 的话,那么这些 Cookie 是不会被发送到 InfoQ 的服务器上的”,这里是不是我理解错了还是写错了。应该是不会发送到极客时间的服务器上,或者说极客时间的某些Cookie设置了SameSite = Strict吧。

    作者回复: 我把整个流程写一遍:
    首先假设你发出登录InfoQ的站点请求,然后在InfoQ返回HTTP响应头给浏览器,InfoQ响应头中的某些set-cookie字段如下所示:
    set-cookie: a_value=avalue_xxx; expires=Thu, 21-Nov-2019 03:53:16 GMT; path=/; domain=.infoq.com; SameSite=strict
    set-cookie: b_value=bvalue_xxx; expires=Thu, 21-Nov-2019 03:53:16 GMT; path=/; domain=.infoq.com; SameSite=lax
    set-cookie: c_value=cvaule_xxx; expires=Thu, 21-Nov-2019 03:53:16 GMT; path=/; domain=.infoq.com; SameSite=none
    set-cookie: d_value=dvaule_xxxx; expires=Thu, 21-Nov-2019 03:53:16 GMT; path=/; domain=.infoq.com;


    我们可以看出,
    a_value的SameSite属性设置成了strict,
    b_value的SameSite属性设置成了lax
    c_value的SameSite属性值设置成了none
    d_value没有设置SameSite属性值


    好,这些Cookie设置好之后,当你再次在InfoQ的页面内部请求InfoQ的资源时,这些Cookie信息都会被附加到HTTP的请求头中,如下所示:
    cookie: a_value=avalue_xxx;b_value=bvalue_xxx;c_value=cvaule_xxx;d_value=dvaule_xxxx;

    但是,假如你从time.geekbang.org的页面中,通过a标签打开页面,如下所示:
    <a href="https://www.infoq.cn/sendcoin?user=hacker&number=100">点我下载</a>
    当用户点击整个链接的时候,因为InfoQ中a_vaule的SameSite的值设置成了strict,那么a_vaule的值将不会被携带到这个请求的HTTP头中。

    如果time.geekbang.org的页面中,有通过img来加载的infoq的资源代码,如下所示:
     <img src="https://www.infoq.cn/sendcoin?user=hacker&number=100">
    那么在加载infoQ资源的时候,只会携带c_value,和d_value的值。


    这样写不知道你明白没有,如果还有疑惑欢迎继续提问。

    2019-10-22
    2
    2
  • 蓝配鸡
    有个疑问:
    same origin policy不是确保了不同域名时间不可以访问数据的吗? 那第三方站点如何拿到cookie和session?

    谢谢老师🙏

    作者回复: 如果是CSRF攻击,那么黑客是拿不到受害者站点数据的。

    但是黑客会在他的A站点中调用受害者B站点的http接口,这些接口可以是转账,删帖或者设置等。

    这个过程中你需要注意一点,在黑客A站点中调用受害者B站点的http接口时,默认情况下,浏览器依然会把受害者的Cookie等信息数据发送到受害者的B站点,【注意这里并不是黑客的A站点】。

    如果B站点存在漏洞的话,那么黑客就会攻击成功,比如将受害者的金币转出去了!

    这样解释不知道问你清楚了没有?

    2019-10-22
    4
    1
  • 昆虫捕手
    CSRF TOKEN类似于cookie, 都是存储用户信息,而此用户信息只存储在当前你请求的站点,而不是浏览器,所以不同的标签页面,或不同次的请求是不共享此用户信息的,所以规避了cookie所带来的的漏洞,老师,我这样理解对?

    作者回复: 是的,针对于请求的,比如同一个浏览器打开两个相同页面,那么服务器为这两个页面生成的csrf token都是不同的

    2019-11-29
  • lee
    在前后端分离的项目里面,是不是服务器端设置了access-control-allow-arigin只允许受信任的站点访问接口也可以防止CSRF攻击?
    2019-11-18
  • 可笑的霸王
    老师,关于Referrer服务器验证不太稳定可以详细解释下吗,因为我看到Referrer-Policy也可以设置为origin,达到Origin类似的效果
    2019-10-23
  • Chao
    chrome 默认启用 SameSite 了
    2019-10-22
收起评论
8
返回
顶部