ToB企服应用市场:ToB评测及商务社交产业平台

标题: CSRF攻防 [打印本页]

作者: 饭宝 时间: 2024-4-20 03:20
标题: CSRF攻防
早在2018年就了解CSRF，偶然间注意到项目的VerifyCsrfToken中间件，心血来潮，于是就写了这篇文章。
简介

CSRF (跨站请求伪造）,或称之为XSRF, 是一种网络安全漏洞，黑客借用（不一定是盗用）受害者在已经登录过的网站上存留的会话凭证，作为通行证，借用受害者的身份实施的攻击行为。
CSRF特点：属于攻击方式隐蔽，非硬扛目标服务器。身份伪造，危害性大。难以排查，因为请求都是合法请求。
与XSS区别

标题XSSCSRF极简概括项目被植入恶意客户端代码，被受害者客户端执行的行为。利用客户端会话冒充用户身份做坏事的行为。对登录凭证的影响植入恶意代码盗取会话凭证利用会话凭证冒充真实用户注意：

如果cookie设置了HttpOnly，XSS将无法获取cookie。
XSS能比CSRF做更多的攻击行为，但与CSRF不存在包含关系，而是并列关系，两者攻击方式可以结合。

举例

场景一：常规手段

小明登录了安全性不高的网站A，小明的浏览器自然就记录了cookie，黑客也熟悉这个网站A，知道有个更改登录密码的接口：/api/change_pwd?new_pwd=xxx，于是黑客做了一个网站B，小明点进去网站B后，此时小明的密码已被重置为12345678。
场景二：CSRF联合XSS

小明登录了安全性不高的网站A，小明的浏览器自然就记录了cookie，黑客也熟悉这个网站A，知道有个更改登录密码的接口：/api/change_pwd?new_pwd=xxx，也知道这个项目有存储型XSS漏洞，但是网站A的cookie设置了HttpOnly属性，导致恶意代码无法获取cookie，好在可以利用存储型XSS伪造一个提交按钮或者具有诱导性图片，小明点击了这个按钮或图片，此时小明的密码已被重置为12345678。
原理解析

诱导小明点击网站B（这里不纠结是社工引导），又或者是网站A伪造的图片或按钮，背后都有一个触发/api/change_pwd?new_pwd=12345678的链接，触发后，请求了网站A的重置密码接口，浏览器自然而然的带上了登录的cookie，很顺利的更改了登录密码。
防御

维护层面（不保险）

网上一些开源项目被很多用户使用，这些项目无法保证一定没有CSRF漏洞，搞不好就是群体性网络安全事件，及时更新补丁，及时排查。
弃用get（不保险）

可以使用POST，避免一个链接就引发的CSRF攻击。
弃用cookie改用token（不保险）

只要浏览器存有cookie，哪怕请求是一个图片也会被带上cookie信息。改用LocalStorage存token后，默认任何请求不会携带token，利用js仅让请求业务接口时带上token就好。
检测referer（不保险）

referer是浏览器请求头的一个属性，用于检测当前请求的资源，是来源于那个页面，如果没有这个属性，那就是本页面。
服务端可以在业务代码前，检测referer的值，如果不是受信任的站点，直接拒绝。注意referer可以伪造。
添加验证码（还行）

关键的节点可以添加验证码的前置验证，通过蹦出来的验证码阻断恶意请求。
如果每个请求都加，用户体感很不好。
添加csrf_token（保险）

前提要保证，有CSRF风险的接口，不允许GET请求，除了GET请求之外的全部需要CSRF_TOKEN，从而实现安全隔离。

MVC架构（非GET请求下）：生成一个复杂的随机字符串作为csrf_token，把这个token存入新的session中，并让页面表单的隐藏域填充csrf_token的值（csrf_token和session中的token是一致的），当表单提交时，服务端需要优先验证表单的csrf_token与session中存的是否一致，如果不存在，失败掉这次请求，如果对不上，也失败掉这次请求。
当黑客实施csrf攻击时，黑客猜不到token，就能防止csrf（但遇到XSS可能会直接窃取表单中的csrf_token，只能说见招拆招，不断完善）。
前后端分离架构：直接用token。

为什么我认为get请求不需要csrf_token?

get是用来获取数据的，一般可以定义为检索数据，没有写操作。get也可以添加csrf_token，技术上能实现，但是可能增加复杂度，并且大部分业务场景下不需要。
为什么csrf_token要放置在session中，而不放置在cookie中？

若直接将csrf_token明文放入cookie：然后表单提交时同步提交隐藏域的csrf_token和cookie，然后服务端作对比，很明显自欺欺人。
若服务端直接将csrf_token不可逆加密后放入cookie：然后表单提交时同步提交csrf_token和cookie，由于没有和服务端强绑定，即使验证是在服务端，但张三的令牌和李四的令牌都能互相使用，还是不够安全。如果是开源项目，或黑客破解了简单的csrf加密算法，那么此时可以依据破解出来的算法任意伪造token。
所以必须要求与服务端强绑定。

前后端分离的架构，用cookie存令牌，还需要csrf_token吗？

没必要，因为有了也不安全。因为用cookie存令牌，csrf_token也无法像MVC那样，在页面加载时同步生成，需要请求接口，期间并不安全（下文有讲）。
为什么前后端分离的架构，不推荐用csrf_token?

鉴权会使用存入LocalStorage/SessionStorage的登录凭证（access token）而不是cookie。黑客实施csrf攻击，默认情况下，请求不会自动带上LocalStorage/SessionStorage的登录凭证，也就无法伪造身份。
如果强制使用csrf_token，页面加载时请求接口获取csrf_token，此时还未登录，服务器无法认定客户端是谁，就随意下发token，那么黑客可以直接请求接口去获取，甚至造成接口滥用现象，完全没必要。

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！

欢迎光临 ToB企服应用市场:ToB评测及商务社交产业平台 (https://dis.qidao123.com/)