跨站请求伪造 CSRF

什么是CSRF

CSRF全称 Cross‑Site Request Forgery，跨站请求伪造，也叫一键攻击、会话劫持攻击，属于被动攻击。

简单理解：攻击者盗用你的登录身份，以你的名义发送恶意请求。网站只校验Cookie确认身份，但无法判断这个请求是不是用户本人自愿发起的。

攻击前提（两个条件必须同时满足）

1. 用户已经登录目标网站，浏览器本地保存网站登录Cookie，没有登出。
2. 用户在同一个浏览器，打开新标签访问黑客准备的恶意网站。

攻击举例（模拟银行转账）

1. 用户A登录银行网站，浏览器保存银行网站的Cookie。
2. 用户A没有退出银行页面，又打开标签访问恶意网站B。
3. 恶意网站B页面里面藏有恶意代码（隐藏图片、自动提交表单），偷偷向银行网站发送转账请求。
4. 浏览器发起请求时，自动带上银行网站的Cookie。
5. 银行服务器校验Cookie有效，误认为是用户自己操作，完成转账。

GET方式简单攻击示例

恶意页面内写一张看不见的图片，加载图片就自动触发转账请求：

<img src="http://www.mybank.com/Transfer.php?toBankId=11&money=1000" />Code language: HTML, XML (xml)

误区：改成POST请求不能解决CSRF，黑客可以用JS构造表单自动提交POST请求，依旧可以完成攻击。

安全漏洞扫描工具经常可以扫描出CSRF漏洞。

CSRF与XSS简单区分

• XSS（跨站脚本）：注入恶意JS脚本，盗取Cookie，控制浏览器。
• CSRF（跨站请求伪造）：不需要偷Cookie，直接利用浏览器自动携带Cookie的特性，冒充用户发请求。

CSRF解决方案（服务端防御为主）

1. CSRF‑Token 令牌方案（最主流有效）

1. 服务器为用户会话生成一个随机不可预测的Token，存放在Session中。
2. 页面表单增加隐藏域，把这个Token嵌入页面一起返回浏览器。
3. 用户提交表单的时候，必须带上这个Token。
4. 服务器校验提交上来的Token和Session保存的Token是否一致；不一致直接拒绝请求。

黑客的恶意网站无法获取到这个随机Token，就无法伪造合法请求。

2. Cookie设置SameSite属性

设置Cookie的SameSite=Lax / SameSite=Strict，浏览器在跨站场景下不会自动携带Cookie，从源头抑制CSRF攻击。

3. 校验请求来源 Referer / Origin

服务器检查HTTP请求头，判断请求来源域名是否为本网站；拒绝来自外部站点的请求。

缺点：部分浏览器可以禁用Referer，只能做辅助防护，不能单独依靠该方案。

4. 高危操作二次校验

转账、修改密码、修改重要资料等敏感操作，增加验证码、再次输入密码确认，就算请求被伪造，也无法完成操作。

补充：ASP.NET、Spring、Django等主流Web框架都内置CSRF防护功能，开发时需要手动开启。