属于CSRF漏洞防护方法

一个凌晨两点，属于某电商平台的漏洞安全工程师盯着监控大屏，冷汗顺着脊背流下来——攻击者仅仅用了一封带图片的防护方法邮件，就清空了三百个用户的属于余额。图片里藏的漏洞链接，正是防护方法CSRF攻击的典型手法：受害者浏览器自动携带Cookie，向服务器发送了“转账”请求。属于服务器信了，漏洞因为它只认Cookie，防护方法不认“人”。属于

CSRF的漏洞本质，是防护方法浏览器把“用户的身份凭证”当成了“用户的意图”。防护的属于核心，就是漏洞打破这层信任——让服务器能区分“用户主动操作”和“恶意伪造请求”。

最硬核的防护方法办法是同步令牌（Synchronizer Token）。服务器在渲染表单时生成一个随机token，存在session里，同时塞进隐藏字段。提交时服务器比对两者是否一致。攻击者没法读取同源响应，自然拿不到token。这法子有效，但有个坑：如果网站有XSS漏洞，token会被偷走。所以它必须和输出编码配合，单打独斗会翻车。

另一个常见方案是双提交Cookie（Double Submit Cookie）。不存session，只在Cookie里放一个随机值，同时要求请求参数里带同样的值。服务器只比对两者是否相等。好处是无状态，适合分布式架构。坏处是如果攻击者能控制子域名（比如通过DNS rebinding或CNAME劫持），就能往主域名写Cookie，那这层防线就形同虚设。我见过不少团队图省事用这个，却没排查子域名的安全性。

还有一招是校验Origin/Referer头。POST请求必须带合法来源。这方法成本最低，但Referer可能因隐私策略被浏览器省略，Origin在跨域时又未必可靠。更麻烦的是，有些老系统内嵌了第三方支付回调，来源头经常变化，误伤率极高。所以它更适合做辅助防线，而不是主防。

真正让我觉得“靠谱”的组合拳是：SameSite Cookie属性 + 自定义请求头。把Session Cookie设为SameSite=Lax或Strict，浏览器会在跨站请求时自动不携带Cookie。这是浏览器层面的原生隔离，攻击者伪造的跨站请求直接“裸奔”。但注意，Lax模式下，GET请求的顶层导航仍会带Cookie——比如用户点开一个恶意链接跳转，GET请求依然有效。所以对状态变更操作，必须用POST，并且再加一个自定义头，比如X-Requested-With: XMLHttpRequest。服务器只接受带这个头的POST请求，而跨站表单提交没法自定义头（除非CORS放行）。

说个真实案例。某金融App曾经只用Referer校验，结果被安卓WebView的loadUrl接口绕过——因为WebView里Referer可以随便改。后来他们改成双重校验：SameSite=Strict + 每个接口校验token，线上再没出过CSRF事件。你看，防护不是选一个方法，而是理解攻击面后叠加。

还有个细节容易被忽略：JSON接口也要防。有些开发者觉得CSRF只针对表单，其实application/json的POST请求也能被跨站发送——用fetch配合mode: 'no-cors'，只是服务器收不到数据而已。但如果接口设计成接收text/plain或application/x-www-form-urlencoded，那照样中招。所以别只盯着Content-Type，要检查接口是否接受非标准格式。

最后说点个人观察。很多团队在防护时陷入误区：过度依赖框架内置的CSRF中间件，却不理解其原理。Django的CSRF token默认只校验POST，但如果你开了@csrf_exempt给某些API，又没仔细评估，漏洞就悄悄露头。更可怕的是，有些开发者把token放在localStorage里，然后通过JS读取——这等于把钥匙放在门口地垫下，XSS一来全完蛋。

防护CSRF没有银弹，但有一条铁律：任何敏感操作，都不能只靠浏览器自动携带的凭证来验证身份。你得多问一句：这个请求，真的是用户本人想发的吗？多一层校验，多一分安全。别嫌麻烦，凌晨两点的报警声，比写代码时多敲两行费事多了。

(责任编辑：焦点)