2024年WEB安全之-CSRF（跨站请求伪造），2024年最新持续更新中

最新推荐文章于 2024-11-05 15:26:40 发布

2401_84301948

最新推荐文章于 2024-11-05 15:26:40 发布

阅读量1k

点赞数 20

分类专栏：程序员文章标签：网络安全学习面试

本文链接：https://blog.csdn.net/2401_84301948/article/details/138681927

版权

程序员专栏收录该内容

155 篇文章 2 订阅

订阅专栏

学习路线：

这个方向初期比较容易入门一些，掌握一些基本技术，拿起各种现成的工具就可以开黑了。不过，要想从脚本小子变成黑客大神，这个方向越往后，需要学习和掌握的东西就会越来越多以下是网络渗透需要学习的内容：
在这里插入图片描述

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化资料的朋友，可以点击这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

看到这里，你也许会问：“如果我不满足以上两个条件中的一个，我就不会受到CSRF攻击”。是滴，确实如此，但是你不能保证以下情况不会发生：

你不能保证你登录了一个网站之后，不再打开一个tab页面并访问其它的网站（黄网）。
你不能保证你关闭浏览器之后，你本地的Cookie立刻过期，你上次的会话已经结束。

上述中所谓的攻击网站，可能就是一个钓鱼网站或者黄色网站。

几种常见的攻击类型

GET类型的CSRF

这种类型的CSRF一般是由于程序员安全意识不强造成的。GET类型的CSRF利用非常简单，只需要一个HTTP请求，所以，一般会这样利用：

在访问含有这个img的页面后，成功向http://wooyun.org/csrf?xx=11 发出了一次HTTP请求。

所以，如果将该网址替换为存在GET型CSRF的地址，就能完成攻击了。

POST类型的CSRF

这种类型的CSRF危害没有GET型的大，利用起来通常使用的是一个自动提交的表单，如：

访问该页面后，表单会自动提交，相当于模拟用户完成了一次POST操作。

CSRF如何防御

验证HTTP Referer字段

根据HTTP协议，在HTTP头部中有一个Referer字段，它记录了该HTTP请求所在的地址，表示HTTP请求从那个页面发出的。比如当你访问 http://zhifubao.com/withdraw?account=lyq&amount=10000&for=xxx ，用户必须先登录支付宝网站，然后通过点击页面的的按钮来触发转账事件。此时，转账请求的Referer值就是转账页面所在的URL，通常是以zhifubao.com域名开头的地址。如果攻击者要实行CSRF攻击，那么他只能在自己的站点构造请求，此时Referer的值就指向黑客自己的网站。因此要防御CSRF攻击，支付宝只需要对每一个转账请求验证其Referer值，如果是以zhifubao.com开头的域名，则是合法请求，相反，则是非法请求并拒绝。

这种方法的好处就是简单易行，只需要在后台添加一个拦截器来检查Referer即可。然而这种办法并不是万无一失，Referer的值是由浏览器提供的，一些低级的浏览器可以通过某种方式篡改Referer的值，这就给了攻击者可乘之机；而一些高级浏览器处于安全考虑，可以让用户设置发送HTTP请求时不再提供Referer值，这样当他们正常访问支付宝网站时，因为没有提供Referer值而被误认为CERF攻击，拒绝访问。

充分利用好cookie的SameSite属性

SameSite选项通常由Strict、Lax和None三个值

Strict最为严格，如果cookie设置了Strict，那么浏览器会完全禁止第三方Cookie。
Lax相对宽松一点，在跨站点的情况下，从第三方站点的链接打开和从第三方站点提交Get的表单都会携带cookie.但是如果在第三方站点中使用Post方法或者通过img、iframe等标签加载的URL,都不会携带Cookie。
None, 任何情况下都会发送Cookie。

但是现在大部分的网站静态资源都放在单独的域名下，所以通过设置Cookie的SameSite为Strict、Lax是不能正常运行的，所以这个方法只适用静态资源跟服务器接口在同一个站点下的网站。

在请求地址中添加 token 并验证

CSRF 攻击之所以能够成功，是因为黑客可以完全伪造用户的请求，该请求中所有的用户验证信息都是存在于 cookie 中，因此黑客可以在不知道这些验证信息的情况下直接利用用户自己的 cookie 来通过安全验证。要抵御 CSRF，关键在于在请求中放入黑客所不能伪造的信息，并且该信息不存在于 cookie 之中。可以在 HTTP 请求中以参数的形式加入一个随机产生的 token，并在服务器端建立一个拦截器来验证这个 token，如果请求中没有 token 或者 token 内容不正确，则认为可能是 CSRF 攻击而拒绝该请求。

这种方法要比检查 Referer 要安全一些，token 可以在用户登陆后产生并放于 session 之中，然后在每次请求时把 token 从 session 中拿出，与请求中的 token 进行比对，但这种方法的难点在于如何把 token 以参数的形式加入请求。对于 GET 请求，token 将附在请求地址之后，这样 URL 就变成 http://url?csrftoken=tokenvalue。而对于 POST 请求来说，要在 form 的最后加上 <input type=”hidden” name=”csrftoken” value=”tokenvalue”/>，这样就把 token 以参数的形式加入请求了。但是，在一个网站中，可以接受请求的地方非常多，要对于每一个请求都加上 token 是很麻烦的，并且很容易漏掉，通常使用的方法就是在每次页面加载时，使用 javascript 遍历整个 dom 树，对于 dom 中所有的 a 和 form 标签后加入 token。这样可以解决大部分的请求，但是对于在页面加载之后动态生成的 html 代码，这种方法就没有作用，还需要程序员在编码时手动添加 token。

该方法还有一个缺点是难以保证 token 本身的安全。特别是在一些论坛之类支持用户自己发表内容的网站，黑客可以在上面发布自己个人网站的地址。由于系统也会在这个地址后面加上 token，黑客可以在自己的网站上得到这个 token，并马上就可以发动 CSRF 攻击。为了避免这一点，系统可以在添加 token 的时候增加一个判断，如果这个链接是链到自己本站的，就在后面添加 token，如果是通向外网则不加。不过，即使这个 csrftoken 不以参数的形式附加在请求之中，黑客的网站也同样可以通过 Referer 来得到这个 token 值以发动 CSRF 攻击。这也是一些用户喜欢手动关闭浏览器 Referer 功能的原因。