csrf漏洞测试

去年帮一个朋友看他的漏洞博客后台，发现一个有意思的测试现象：他写文章时用的富文本编辑器，保存草稿的漏洞接口居然没做任何CSRF防护。我随手构造了一个页面，测试在他登录状态下访问，漏洞草稿就被改成了“Hacked by CSRF”。测试他当时就懵了——明明没点任何按钮，漏洞怎么数据就变了？测试

这就是CSRF的典型场景。它的漏洞核心逻辑很简单：浏览器会自动带上目标站点的Cookie，而服务端只认Cookie不认人。测试攻击者不需要拿到你的漏洞密码，只要让你在登录状态下访问一个恶意页面，测试就能以你的漏洞身份发请求。听起来像魔法，测试其实只是漏洞浏览器太“听话”了。

测试CSRF漏洞，第一步是找那些“只靠Cookie鉴权、没有额外令牌”的接口。比如修改密码、发帖、转账、改邮箱。我习惯先抓一个正常请求，看它有没有csrf_token之类的参数。如果没有，再检查Referer或Origin头是否被严格校验。很多老系统只检查Referer里是否包含自己的域名，这种用https://evil.com/yourdomain.com就能绕过。

构造PoC页面时，最省事的是用<form>自动提交。比如：

<form action="https://target.com/change_email" method="POST"> <input type="hidden" name="email" value="attacker@evil.com"> </form> <script>document.forms[0].submit();</script> 

把这段代码放到自己的服务器上，诱使目标用户访问。如果对方恰好登录着target.com，邮箱就被改了。整个过程用户看不到任何跳转，因为表单提交后目标站点可能返回一个空白页或302，攻击者用iframe隐藏结果就行。

但现实没那么顺利。现在主流浏览器默认SameSite=Lax，跨站POST请求不会带Cookie。所以测试时得先确认目标站点的Cookie有没有设置SameSite=None; Secure。如果没有，那CSRF基本打不动。我遇到过一些站点，登录Cookie是SameSite=Lax，但有个别功能Cookie是SameSite=None，那就要针对那个功能单独测。

另一种情况是接口用Content-Type: application/json。这种没法用简单表单提交，得用fetch加mode: 'no-cors'，但这样又读不到响应。不过如果只是触发写操作，不关心返回内容，那还是能打。比如：

fetch('https://target.com/api/delete_account', {  method: 'POST', credentials: 'include', headers: { 'Content-Type': 'application/json'}, body: JSON.stringify({ confirm: true}) }); 

注意，这段代码在跨站环境下，浏览器会先发一个OPTIONS预检请求。如果服务端没正确响应CORS头，请求根本发不出去。所以JSON接口的CSRF利用门槛更高，但一旦服务端CORS配置成Access-Control-Allow-Origin: *且允许凭据，那就彻底沦陷。

测试时我习惯用Burp Suite的CSRF PoC生成器，它能把抓到的请求一键转成HTML表单。但别全信它——生成的代码有时会漏掉enctype或method。手动改一遍更稳。另外，如果目标接口要求X-Requested-With: XMLHttpRequest，那普通表单打不了，得用Flash或XHR，现在基本没戏。

最后说个真实案例。某次测一个电商后台，删除收货地址的接口是GET /address/delete?id=123。没有token，没有Referer检查。我写了个<img src="https://target.com/address/delete?id=123">，放在论坛签名里。只要管理员登录后看了那个帖子，地址就没了。这种用GET做写操作的，连表单都不用，一个图片标签就搞定。

CSRF的测试成本很低，但危害不小。别指望所有站点都上了SameSite和token，老系统、内部工具、API网关后面藏着的接口，往往就是缺口。测的时候多问一句：这个请求，浏览器会自动带上什么凭证？如果答案是“Cookie”，那就值得试试。