Web安全之CSRF（跨站请求伪造）的底层原理、攻击场景与防御策略详解

描述
CSRF（Cross-Site Request Forgery，跨站请求伪造）是一种攻击者诱导受害者在已登录目标网站的状态下，执行非本意操作的攻击方式。它利用了Web应用程序对用户浏览器的信任，通过伪造受信任用户的请求来执行非法操作。与XSS攻击不同，CSRF攻击的重点是“请求伪造”而非“脚本注入”。

循序渐进讲解

第一步：理解CSRF攻击的核心前提
CSRF攻击能够成功，依赖于以下三个关键条件同时满足：

1. 用户已登录目标网站：浏览器中保存了目标网站的有效会话（如Cookie、Session）。
2. 目标网站未对敏感操作做足够验证：服务器仅依赖Cookie等自动携带的凭证来验证请求，未校验请求的来源或额外令牌。
3. 用户访问恶意页面：攻击者诱导用户点击恶意链接、图片或访问恶意网站。

第二步：深入剖析CSRF攻击的底层原理
浏览器在向某个域名发送请求时，会自动携带该域名下的Cookie（包括会话Cookie）。这是浏览器的同源策略中允许的行为，也是CSRF攻击的根源。

攻击流程示例：

1. 用户登录银行网站bank.com，服务器返回会话Cookie（例如sessionid=abc123）。
2. 用户未退出登录，访问了攻击者构造的恶意页面evil.com。
3. 该页面隐藏了一个表单，自动提交转账请求到bank.com/transfer：

   <form action="https://bank.com/transfer" method="POST">
     <input type="hidden" name="to" value="attacker_account">
     <input type="hidden" name="amount" value="10000">
   </form>
   <script>document.forms[0].submit();</script>
   

4. 浏览器向bank.com发送请求时，自动附带了用户的会话Cookiesessionid=abc123。
5. 银行服务器收到带有合法会话Cookie的请求，误认为是用户的自愿操作，执行转账。

关键点：

• 攻击者无法直接获取Cookie内容（同源策略保护），但可利用浏览器自动发送Cookie的机制。
• 请求的发出方是用户的浏览器，而非攻击者的服务器，因此难以追踪。

第三步：CSRF的常见攻击场景与变体

1. GET型CSRF：
   敏感操作通过GET请求完成（如<img src="bank.com/transfer?to=attacker&amount=1000">），诱导用户加载图片时触发。
2. POST型CSRF：
   如上例，通过表单自动提交。
3. JSON类型绕过：
   如果网站使用JSON格式传输数据，但未校验Content-Type或依赖Cookie认证，攻击者可通过构造表单或Flash发送请求。

第四步：防御策略的逐层设计
防御核心是“区分请求是否来自用户本意”。需采用多重防御组合：

1. 同源检测（Origin/Referer校验）

• 服务端校验HTTP请求头中的Origin或Referer字段，判断请求来源是否在白名单内。
• Origin：包含协议、域名、端口，适用于POST请求。
• Referer：包含来源页面的完整URL，但可能被浏览器隐私设置过滤。
• 局限性：子域名伪造、Referer缺失时需放行。

2. CSRF Token（最常用且有效）

• 原理：服务器生成随机令牌（Token），嵌入表单或请求头，执行操作时验证令牌是否匹配。
• 实现方式：
  a. 表单Token：渲染页面时，将Token放入表单隐藏域。
  b. 自定义请求头：通过JavaScript添加Token（如X-CSRF-Token）。
• 关键要求：
  • Token需足够随机（如使用加密安全随机数生成器）。
  • Token绑定用户会话，每次会话或请求更新。
  • 敏感操作均验证Token。

3. 双重Cookie验证

• 将Token放在Cookie中，同时请求时从Cookie读取Token，放入请求体或请求头。
• 服务器比较两者是否一致。
• 优点：无需服务器存储Token状态。
• 缺点：子域名安全需注意（设置Cookie作用域）。

4. SameSite Cookie属性

• 设置Cookie的SameSite属性为Strict或Lax，限制跨站请求自动携带Cookie。
• Strict：完全禁止跨站携带Cookie。
• Lax：允许部分安全请求（如导航链接）携带Cookie。
• 注意：老旧浏览器兼容性问题。

5. 用户交互验证

• 敏感操作前要求用户进行二次验证（如输入密码、验证码、短信确认）。
• 可有效防御CSRF，但影响用户体验。

第五步：防御策略的实践组合

• 基础组合：SameSite Cookie + CSRF Token。
• 加强防御：对敏感操作增加Origin校验和用户交互验证。
• 注意事项：
  • Token需防预测，避免通过URL暴露（防止泄露）。
  • 避免将Token通过GET参数传递，以防被日志记录。
  • 登录态Cookie设置为HttpOnly（防XSS窃取，但对CSRF防御无效）。

第六步：特殊场景的防御考量

• 单页应用（SPA）：
  • 将Token存储在内存或非HttpOnly的Cookie中，通过JavaScript读取并添加到请求头。
• API服务：
  • 使用OAuth 2.0的Bearer Token认证，代替Cookie认证。
• 文件上传CSRF：
  • 部分浏览器允许通过<input type="file">构造文件上传请求，需单独校验Token。

总结
CSRF攻击本质是“利用浏览器的自动凭证发送机制”，防御核心是“确保请求来自可信来源并携带额外凭证”。通过SameSite Cookie降低基础风险，结合CSRF Token和同源校验构建纵深防御，同时对敏感操作增加交互验证，可有效抵御绝大多数CSRF攻击。