无需登录 数据私有 本地保存

CSRF Token 验证模拟器 - 理解防护流程

10
0
0
0

CSRF Token 验证模拟器

CSRF 防护
已启用
🏦 银行网站 (bank.example.com) 安全连接 🔒
已登录用户
user_zhang@bank.example.com
会话活跃
账户余额
¥ 50,000.00
当前 CSRF Token（隐藏表单字段）
csrf_token
dG9rZW4tYTFiMmMzLWU0ZjUtNmc3aC04aTlq
此 Token 随页面加载，存储在隐藏的 <input type="hidden"> 中
📝 正常转账表单
<input type="hidden" name="csrf_token" value="dG9rZW4t...">
⚠️ 恶意网站 (evil.example.org) 危险 ⚡
攻击者页面：伪装成"免费抽奖"，利用您的登录状态发起伪造请求
🎁
恭喜！您中奖了！
点击领取iPhone 15 Pro Max
此按钮实际会向银行发送转账请求
🔍 页面隐藏的恶意表单
<!-- 隐藏的自动提交表单 -->
<form
action=
"https://bank.example.com/transfer"
method=
"POST"
id=
"stealForm"
>
<!-- ⚠️ 没有 csrf_token 字段！ -->
<input name="to" value="攻击者账户">
<input name="amount" value="9999">
</form>
<script>document.getElementById('stealForm').submit();</script>
恶意网站无法读取银行域下的CSRF Token（同源策略保护），因此伪造的请求中缺少有效Token
请求验证日志（服务器视角）
等待请求... 提交转账或点击恶意按钮来观察验证结果
CSRF Token 防护流程
1 用户登录
银行建立会话，生成CSRF Token存入服务器Session
2 Token嵌入页面
Token通过隐藏字段嵌入表单，随HTML返回
3 攻击者伪造请求
恶意网站发起POST请求，但无法获取Token
4 服务器验证
比对请求Token与Session Token，不匹配则拒绝
常见问题与知识点
🔍 什么是CSRF攻击？

CSRF（Cross-Site Request Forgery，跨站请求伪造）是一种网络攻击手段。攻击者诱导已登录用户访问恶意网站，利用用户在目标网站的有效会话，以用户的名义发送伪造的请求。

举例：您登录了银行网站后，在另一个标签页打开了恶意网站。恶意网站中的隐藏表单自动向银行发起转账请求。由于浏览器会自动携带银行Cookie，如果银行没有CSRF防护，这笔转账就会成功执行。

🛡️ CSRF Token 如何防止攻击？

核心原理：CSRF Token是一个随机生成的、与用户会话绑定的唯一字符串。它的防护逻辑基于一个关键事实：

  • 同源策略阻止恶意网站读取银行域下的页面内容，因此攻击者无法获取CSRF Token。
  • 银行服务器在收到请求时，验证请求中的Token是否与服务器存储的Token一致。
  • 恶意请求缺少有效Token → 验证失败 → 请求被拒绝。
📋 CSRF Token 应该放在哪里？

常见的存放位置有：

  1. HTML表单隐藏字段：<input type="hidden" name="csrf_token" value="..."> — 最传统的方式。
  2. HTTP请求头：如 X-CSRF-Token 或 X-XSRF-Token，常用于AJAX请求。
  3. 双重Cookie验证：Token同时存储在Cookie和请求参数/头中，服务器比对两者。

⚠️ 注意：不要将CSRF Token放在URL查询参数中，因为URL可能被Referer头泄露或被浏览器历史记录保存。

🔄 CSRF 与 XSS 有什么区别？
特性CSRFXSS
攻击目标利用用户已认证的会话在用户浏览器中执行恶意脚本
攻击方式伪造跨站请求注入恶意代码到页面
是否读取响应通常不能读取响应可以读取页面内容
防护措施CSRF Token、SameSite Cookie输出编码、CSP、输入验证
同源策略绕过（利用Cookie自动携带）在同源内执行

💡 关键区别：XSS可以在页面中执行任意JS代码，因此如果存在XSS漏洞，CSRF Token防护也会被绕过（攻击者可以读取Token）。

🍪 SameSite Cookie 是什么？

SameSite是Cookie的一个属性，用于控制Cookie在跨站请求中是否发送：

  • SameSite=Strict：完全禁止跨站发送Cookie，防护最严格。但用户从外部链接进入网站时可能影响体验。
  • SameSite=Lax：大多数跨站GET请求不发送Cookie，但顶级导航（如点击链接）除外。现代浏览器的默认值。
  • SameSite=None：允许跨站发送，但必须同时设置Secure属性（仅HTTPS）。

📌 现代浏览器（Chrome 80+）默认使用SameSite=Lax，这本身就能防御大部分CSRF攻击。但CSRF Token仍然是纵深防御的重要一环。

🔑 CSRF Token 应该如何生成？

安全的CSRF Token生成应满足：

  • 足够随机：使用密码学安全的随机数生成器（如crypto.randomBytes()）。
  • 与会话绑定：每个用户会话生成独立Token，或每次请求生成新Token。
  • 足够长度：建议至少128位（16字节）随机数据。
  • 时效性：可设置过期时间，超时后需要刷新。
  • 一次性使用（可选）：每次使用后更换Token，防止重放攻击。
📱 单页应用（SPA）中如何处理CSRF Token？

在SPA中，常见的做法是：

  1. 登录成功后，服务器在响应头或响应体中返回CSRF Token。
  2. 前端将Token存储在内存或sessionStorage中（不要存储在localStorage中，因为易受XSS攻击）。
  3. 每次发送POST/PUT/DELETE等请求时，在请求头（如X-CSRF-Token）中携带Token。
  4. 或者使用双重Cookie模式：服务器设置一个csrf_token Cookie（非HttpOnly），前端读取后通过请求头发送，服务器比对两者。
❓ 关闭CSRF防护会怎样？（试试上面的开关）

当您在上方关闭CSRF防护开关后：

  • 服务器不再验证CSRF Token。
  • 恶意网站发起的伪造请求将成功执行。
  • 攻击者可以以您的身份进行转账、修改密码等操作。
  • 这正是许多早期Web应用面临的安全漏洞。

⚠️ 在生产环境中，请始终启用CSRF防护！

🔧 相关工具