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

CSRF 令牌生成与验证模拟器 - 跨站请求伪造防护

12
0
0
0

CSRF 令牌生成与验证模拟器

跨站请求伪造（CSRF）防护演示 — 生成令牌、模拟合法请求与伪造攻击

会话令牌数：0 验证通过：0 已拒绝：0
CSRF 攻击流程速览
1 用户登录银行网站，获得会话Cookie
2 用户访问恶意网站（或点击钓鱼链接）
3 恶意网站自动发起跨站请求（如转账）
4 若无CSRF防护，请求携Cookie自动通过

关键点：浏览器自动附带目标域的Cookie，攻击者利用这一点在用户不知情的情况下发起恶意请求。CSRF令牌在请求中增加了一个攻击者无法获取的随机值，从而阻断攻击。

尚未生成令牌，点击上方按钮生成 CSRF 令牌。

模拟场景：银行转账请求

假设用户已登录 bank.example.com，下方分别模拟合法请求（携带有效CSRF令牌）和伪造请求（令牌缺失或无效）。

合法请求（正常表单）

表单中嵌入了有效的CSRF令牌，服务器验证通过。

¥
令牌由服务器生成，嵌入表单隐藏字段
伪造请求（CSRF 攻击模拟）

攻击者构造的表单，令牌缺失或被篡改。

¥
VS
请求日志

暂无请求记录，提交请求后在此查看。

CSRF 常见问题与知识点
什么是 CSRF 攻击？

跨站请求伪造（Cross-Site Request Forgery，CSRF）是一种Web安全漏洞，攻击者诱导用户在已认证的Web应用中执行非预期的操作。

核心原理：浏览器在向某个域名发送请求时，会自动附带该域名的Cookie（包括会话Cookie）。攻击者利用这一点，在用户访问恶意网站时，通过隐藏表单或自动提交的请求，以用户的身份向目标网站发起恶意操作（如转账、修改密码、删除数据等），而用户完全不知情。

典型场景：用户登录银行网站 → 未退出 → 访问了恶意网站 → 恶意网站自动向银行发起转账请求 → 浏览器自动附带银行Cookie → 银行误以为是用户本人操作。

CSRF 令牌（Token）是如何防护的？

CSRF令牌防护采用同步器令牌模式（Synchronizer Token Pattern）：

  1. 服务器生成一个随机、不可预测的令牌，存储在用户会话中。
  2. 令牌通过隐藏表单字段（<input type="hidden">）或HTTP头（如X-CSRF-Token）发送给客户端。
  3. 客户端提交请求时，必须携带该令牌。
  4. 服务器验证请求中的令牌与会话中存储的令牌是否一致，一致则通过，否则拒绝。

为什么有效？攻击者无法读取目标域的Cookie或隐藏字段（同源策略），因此无法获取有效的CSRF令牌，构造的伪造请求将被服务器拒绝。

如何生成安全的 CSRF 令牌？

安全令牌应满足以下要求：

  • 足够随机：使用密码学安全的随机数生成器（如crypto.getRandomValues()），长度至少128位（16字节）。
  • 不可预测：不能使用时间戳、自增ID等可预测的值。
  • 绑定会话：令牌与用户会话绑定，不同用户应有不同令牌。
  • 设置有效期：令牌应有合理过期时间，降低泄露风险。
  • 一次性使用：敏感操作建议使用一次性令牌，使用后立即失效。

本工具使用 crypto.getRandomValues() 生成256位随机令牌，编码为Base64URL格式，确保安全性和URL兼容性。

CSRF 和 XSS 有什么区别？

两者是不同类型的Web安全漏洞：

对比维度CSRFXSS
攻击目标利用用户已认证身份执行操作在用户浏览器中执行恶意脚本
攻击方式跨站伪造请求注入恶意代码
依赖条件用户已登录目标站点网站存在输入输出漏洞
防护手段CSRF令牌、SameSite Cookie输入过滤、输出编码、CSP
影响范围仅限目标站点的操作可窃取数据、劫持会话等

注意：如果存在XSS漏洞，CSRF令牌防护也可能被绕过（攻击者可通过XSS读取令牌），因此两者防护都需要做好。

SameSite Cookie 能替代 CSRF 令牌吗？

SameSite是Cookie的一个属性，可以限制Cookie在跨站请求中的发送：

  • SameSite=Strict：完全禁止跨站发送Cookie，防护最严格。
  • SameSite=Lax：允许导航（GET）跨站发送，禁止POST等跨站发送，是Chrome的默认值。
  • SameSite=None：允许跨站发送（需配合Secure标志）。

能完全替代吗？部分场景可以，但建议双重防护：

  • SameSite Lax/Strict 可以防御大多数CSRF攻击。
  • 但老旧浏览器可能不支持SameSite属性。
  • 某些复杂场景（如子域名间请求）可能仍需CSRF令牌。
  • 最佳实践：同时使用CSRF令牌 + SameSite Cookie，形成纵深防御。

本工具主要演示CSRF令牌机制，实际项目中建议结合SameSite属性使用。

AJAX 请求如何携带 CSRF 令牌？

常见方式有几种：

  1. 请求头方式（推荐）：在AJAX请求中添加自定义头，如X-CSRF-Token，服务器从请求头读取验证。
  2. 请求体方式：将令牌作为POST数据的一部分发送。
  3. 双重提交Cookie模式：将令牌同时存储在Cookie和请求头中，服务器比对两者是否一致。

现代前端框架（如React、Vue）通常会在初始化时从页面读取CSRF令牌，并自动添加到每个AJAX请求的头部。后端框架（如Laravel、Django、Spring Security）都提供了内置的CSRF保护机制。

CSRF 防护的最佳实践有哪些？

推荐的多层防护策略：

  1. 使用CSRF令牌：所有状态变更请求（POST/PUT/DELETE）必须携带有效令牌。
  2. 设置SameSite Cookie：将会话Cookie设置为SameSite=Lax或SameSite=Strict。
  3. 验证Referer/Origin头：检查请求来源是否为同源，作为额外防护层。
  4. 敏感操作二次验证：转账、修改密码等操作要求输入密码或验证码。
  5. 合理设置令牌过期时间：平衡安全性与用户体验。
  6. 使用HTTPS：防止令牌在传输中被窃取。
  7. 防范XSS：因为XSS可以绕过CSRF防护读取令牌。

记住：安全是分层的，不要依赖单一防护措施。

🔧 相关工具