前言如果说XSS是利用了用户对网站的信任那么CSRFCross-Site Request Forgery跨站请求伪造则是利用了网站对用户浏览器Cookie的信任。1. 什么是CSRFCSRF全称Cross-Site Request Forgery攻击者诱导受害者在已登录目标网站的情况下点击一个恶意链接或访问一个恶意网页从而伪造受害者的身份向目标网站发送非本意的请求。一句话总结攻击者盗用了你的身份以你的名义发送恶意请求。1.1 举个栗子假设你登录了银行网站 bank.com你的浏览器中保存了有效的Session Cookie。此时你点开了一个攻击者发送的钓鱼邮件邮件中隐藏了一个请求htmlimg srchttp://bank.com/transfer?toattackeramount10000浏览器会自动加载这个图片携带你的Cookie向银行发送转账请求。钱就被转走了。1.2 CSRF的核心特点特点 说明利用身份 受害者的登录态Cookie触发方式 受害者无感知点击恶意链接或页面危害范围 执行敏感操作修改密码、转账、发表言论等2. CSRF与XSS的区别很多人容易混淆这两个漏洞其实它们的本质完全不同对比维度 XSS CSRF信任关系 用户信任网站 网站信任用户浏览器攻击位置 目标网站内部 第三方恶意网站是否需要脚本执行 需要JavaScript执行 不需要仅需构造请求防御重点 输出转义、CSP Token校验、Referer校验简单理解XSS是在目标网站内部执行恶意脚本CSRF是从外部诱导用户向目标网站发送请求3. CSRF的分类3.1 GET型CSRF最常见的形式恶意请求直接拼接在URL中。html!-- 通过图片加载触发 --img srchttp://target.com/delete?id123!-- 或通过超链接诱导点击 --a hrefhttp://target.com/changePwd?newPwd123456点击领取红包/a3.2 POST型CSRF当敏感操作为POST请求时攻击者需要构造一个自动提交的表单。htmlform actionhttp://target.com/transfer methodPOST idhackinput typehidden nameto valueattackerinput typehidden nameamount value10000/formscriptdocument.getElementById(hack).submit();/script3.3 JSON型CSRF进阶当API使用JSON格式接收数据时传统的表单提交无法生效。此时可利用form的enctypetext/plain或Fetch API进行绕过。4. CSRF的利用方式4.1 经典POCProof of Concepthtml!DOCTYPE htmlhtmlheadtitleCSRF Demo/title/headbodyh1恭喜中奖/h1img srchttp://victim.com/api/transfer?tohackeramount10000 styledisplay:none!-- 如果是POST请求 --form actionhttp://victim.com/api/transfer methodPOST idcsrf-forminput typehidden nameto valuehackerinput typehidden nameamount value10000/formscriptdocument.getElementById(csrf-form).submit();/script/body/html4.2 利用iframe进行隐蔽攻击htmliframe srchttp://victim.com/changePwd?newPwd123456 stylewidth:0;height:0;border:0/iframe4.3 结合XSS提升危害当XSS与CSRF结合时威力倍增XSS可以绕过CSRF Token通过读取页面中的TokenXSS可以自动发起CSRF攻击实现蠕虫式传播5. 防御方案、5.1 CSRF Token核心防御原理 CSRF Token工作原理1. 服务器在用户登录后生成一个随机、唯一的 CSRF Token并将其存储在会话中或某个安全的地方如 sessionStorage2. 服务器将 Token 发送给客户端3. 客户端在发起任何敏感操作的请求时都必须将这个 Token 放在HTTP 请求头或 POST 请求体中4. 服务器接收到请求后会验证请求中的 Token 是否与服务器上存储的 Token 相匹配。如果不匹配则拒绝请求实现要点html!-- 表单中包含Token --input typehidden namecsrf_token value随机字符串为什么有效攻击者无法获取当前用户的Token受同源策略保护。5.2 SameSite Cookie属性现代浏览器利器设置Cookie的SameSite属性限制第三方请求携带Cookie。SameSite值 效果Strict 仅允许同站请求携带Cookie最安全Lax 同站请求携带部分跨站GET请求也可携带推荐None 允许所有跨站请求携带需配合SecurehttpSet-Cookie: sessionidxxx; SameSiteLax; Secure5.3 Referer/Origin校验检查请求头中的Referer或Origin验证请求来源是否为可信域名。注意某些场景下Referer可能为空如HTTPS-HTTP需谨慎处理。5.4 双重Cookie验证将CSRF Token同时存储在Cookie中前端读取后放在请求头或请求体中后端比对两者是否一致。5.5 验证码/二次确认对于高风险操作转账、修改密码、删除账号强制要求输入验证码或进行二次认证。6. 如何绕过token1、删除Token参数如果后端没有严格校验Token是否存在服务器可能会直接处理这个没有Token的请求2、将Token值置空如果后端没有对Token值进行非空判断也可能导致绕过3、复用旧的Token有些系统生成的Token在用户会话中是固定的或者允许在一个会话中重复使用同一个Token。攻击者可以先在自己的浏览器上获取一个合法Token然后诱导受害者使用这个Token来发起请求4、配合XSS漏洞窃取Token如果目标网站同时存在XSS跨站脚本攻击漏洞攻击者可以注入恶意脚本让脚本去读取当前页面中的Token值例如从隐藏域或Cookie中然后将窃取到的Token连同恶意请求一起发出。5、Token与Session未绑定如果服务器验证了Token的存在性和正确性但没有将该Token与当前用户的会话Session进行强绑定可以先自己登录网站获取一个属于自己的合法Token然后在构造针对受害者的CSRF攻击POC漏洞验证代码时附上自己的这个Token。7.安全开发Checklist:在开发过程中建议遵循以下原则所有敏感操作POST/PUT/DELETE必须携带CSRF TokenToken必须随机、不可预测、有效期合理Cookie设置SameSiteLax或Strict高风险操作增加二次验证验证码、短信验证避免使用GET请求执行敏感操作校验Referer/Origin设置白名单