浏览器工作原理与实践
李兵
前盛大创新院高级研究员
56402 人已学习
新⼈⾸单¥59
登录后,你可以任选4讲全文学习
课程目录
已完结/共 46 讲
浏览器工作原理与实践
15
15
1.0x
00:00/00:00
登录|注册

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

使用CSRF Token验证
验证请求的来源站点
利用好Cookie的SameSite属性
引诱用户点击链接
自动发起POST请求
自动发起Get请求
SameSite和Origin
HttpOnly机制
Content Security Policy (CSP)
跨域请求资源
可任意引用第三方资源
防御策略
攻击方式
如何防御CSRF攻击?
什么是CSRF攻击?
解决方案
浏览器的“后门”
跨站请求伪造(CSRF)攻击
跨域资源共享(CORS)
思考题
页面安全问题
同源策略
浏览器安全

该思维导图由 AI 生成,仅供参考

上一篇文章中我们讲到了 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/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

CSRF攻击是一种利用用户登录状态发起跨站请求的黑客攻击方式。本文通过一个真实案例和三种攻击方式的示例代码,详细介绍了CSRF攻击的原理和实施方式。与XSS攻击不同,CSRF攻击不需要在用户页面中注入恶意脚本,而是利用服务器漏洞和用户登录状态进行攻击。为了防止CSRF攻击,需要提升服务器的安全性,避免出现CSRF漏洞。读者可以通过了解CSRF攻击的特征和防范手段,加强对服务器安全性的保护,从而有效防止CSRF攻击的发生。 本文首先介绍了利用Cookie的SameSite属性来防止CSRF攻击的方式,通过设置Strict、Lax和None三种模式,可以有效降低CSRF攻击的风险。其次,文章提到了验证请求的来源站点的重要性,通过检查HTTP请求头中的Referer和Origin属性来判断请求是否来自第三方站点。最后,文章介绍了使用CSRF Token来验证请求的有效性,通过在服务器生成Token并在请求中验证,可以有效防止来自第三方站点的CSRF攻击。 总的来说,本文通过深入分析CSRF攻击的原理和实施方式,提出了三种有效的防范手段,包括利用Cookie的SameSite属性、验证请求的来源站点和使用CSRF Token。这些方法可以帮助读者加强对服务器安全性的保护,有效地防止CSRF攻击的发生。文章内容丰富,技术性强,对于想要了解和防范CSRF攻击的读者具有很高的参考价值。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《浏览器工作原理与实践》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(31)

  • 最新
  • 精选
  • “简言之,如果你从极客时间的页面中访问 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
    6
    71
  • 許敲敲
    老师,这方面有比较好的资料或是书嘛?想多了解一下

    作者回复: 主要是根据这几年工作经验和浏览器文档、源码总结出来的,因为维护一个日活跃几千万的浏览器,能带来大量的流量,而流量就是金钱,因此我们的浏览器会遭受到各种类型的攻击,所以我们有很大一部分时间都是在处理攻击! 当然为了写这个专栏,网上web安全相关的书籍我也买了好多,基本都看了一圈,但是有一些问题: 第一是这些书籍都有一些年限了,里面的知识比较滞后! 第二,大多数和前端关系不是太大 第三,大多数写的比较零碎 你们如果发现有好的web安全相关的书籍,也可以推荐下!

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

    作者回复: 如果是CSRF攻击,那么黑客是拿不到受害者站点数据的。 但是黑客会在他的A站点中调用受害者B站点的http接口,这些接口可以是转账,删帖或者设置等。 这个过程中你需要注意一点,在黑客A站点中调用受害者B站点的http接口时,默认情况下,浏览器依然会把受害者的Cookie等信息数据发送到受害者的B站点,【注意这里并不是黑客的A站点】。 如果B站点存在漏洞的话,那么黑客就会攻击成功,比如将受害者的金币转出去了! 这样解释不知道问你清楚了没有?

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

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

    2019-11-29
    5
    11
  • 李小白
    老师,我想请问一下,在浏览器打开第三方站点是如何拿到极客时间站点cookie的?第三方站点和极客时间的站点不同,存在同源策略,所以转账请求验证cookie也是不通过的,那么CSRF是如何攻击的呢?
    2019-10-22
    16
    18
  • Snooker
    1.CSRF是什么: 跨域请求伪造,通过第三方站点模拟用户请求行为 2.如何防范CSRF攻击: 本质就是识别客户端操作是否是用户本人操作 1>.业务上针对重要操作,需要再次验证,如短信验证码等,确保你是你 2>.公司内部做好文档管理:源码、接口文档等,减少信息泄露 3>.服务端针对cookie、session等敏感头信息设置samesite 4>.敏感接口数据采用加密传输、新增时效性或随机参数,增加请求信息不确定性,比如:CSRF Token参数
    2020-06-23
    11
  • Chao
    chrome 默认启用 SameSite 了
    2019-10-22
    10
  • 终于搞懂csrf了(之前看掘金、看书没有示例),学习网络要结合事例,有了事例就能通俗易懂
    2021-01-26
    3
  • lee
    在前后端分离的项目里面,是不是服务器端设置了access-control-allow-arigin只允许受信任的站点访问接口也可以防止CSRF攻击?
    2019-11-18
    2
    3
  • 昵称
    目前为止比较好的防止csrf策略 1:不用cookie,登录态改用token,这样就不会有csrf攻击; 2:重要接口加验证参数:如短信验证码、谷歌验证码验证。即使它发起请求了,没有用户本身的手机验证码、谷歌验证码也通过不了这次请求。
    2020-07-26
    2
收起评论
显示
设置
留言
31
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部