Vulnerability-wiki

跨站请求伪造漏洞（CSRF）

跨站请求伪造（Cross-Site Request Forgery，简称 CSRF）是指，攻击者诱导用户在已登录某个网站的情况下，向该网站发送非本意的请求，从而执行用户权限范围内的敏感操作（如修改邮箱、转账、删除资源等）。

🧠 漏洞原理

CSRF 利用了用户对受信任站点的身份认证信息。当用户登录某网站后，浏览器通常会保留该站点的 Cookie、Session 等身份信息。而攻击者通过构造恶意请求，诱导用户在登录状态下访问攻击链接，从而“伪造”用户的请求。CSRF 的核心在于：浏览器会自动携带用户的 Cookie 等认证信息。

攻击成功的前提：

• 用户已登录目标站点，且登录状态未过期；
• 网站以 Cookie、Session 等隐式方式验证身份；
• 网站未做有效的 CSRF 防御处理（如未校验来源、无 CSRF Token）。

🧪 攻击示例

假设银行网站 https://bank.example.com 提供如下接口：

GET /transfer?to=attacker&amount=10000

用户登录银行网站后未登出，此时访问了攻击者构造的页面：

<img src="https://bank.example.com/transfer?to=attacker&amount=10000" />

若服务器未做验证，这个请求会自动携带用户的 Cookie，服务器认为是用户本人发出的请求，从而完成转账。

💥 常见攻击载体

• <img src="">
• <script src="">
• <iframe src="">
• <form method="POST"> + JavaScript 自动提交
• XMLHttpRequest / Fetch（在部分跨源情况下）

🧷 攻击影响

• 转账操作
• 修改密码或邮箱
• 删除数据（如评论、账号）
• 发布帖子/广告
• 用户隐私信息泄露（部分 API 返回数据）

🛡️ 防御方式

1. 使用 CSRF Token
   • 每个表单请求都包含一个随机生成的 Token；
   • Token 在服务端校验是否合法；
   • 有效防止伪造请求。
2. 双重 Cookie 验证（Double Submit Cookie）
   • 将 Token 放在 Cookie 和请求参数/头中；
   • 服务器检查两者是否一致。
3. Referer / Origin 头检查
   • 拒绝来自非本站域名的请求；
   • 局限在现代浏览器，且 Referer 容易被隐藏。
4. SameSite Cookie 属性
   • 设置 Cookie 的 SameSite=Strict 或 Lax；
   • 限制跨站请求时 Cookie 自动携带。
5. 关键操作确认机制
   • 例如通过图形验证码、短信验证等方式确认操作意图。

✅ 防御示例：CSRF Token 示例（Django）

HTML 页面：

<form method="POST" action="/change_email">
  <input type="email" name="email" />
  <input type="hidden" name="csrf_token" value="">
  <input type="submit" value="提交" />
</form>

后端（Python Flask 示例）：

@app.route('/change_email', methods=['POST'])
def change_email():
    if request.form['csrf_token'] != session['csrf_token']:
        abort(403)
    # 执行邮箱修改操作

🔍 检测方法

• 检查是否存在敏感操作接口；
• 判断该接口是否依赖 Cookie 验证；
• 尝试构造跨站表单、图片等进行测试；
• 浏览器插件辅助检测，如 OWASP CSRFTester。

🧱 案例参考

• CVE-2020-14144 Gitea 在创建 Issue 时未验证 CSRF token，攻击者可诱使受害者提交恶意 Issue 内容
• 许多未验证来源的网站转账/账户设置页面都曾遭遇类似攻击。

🧭 总结

项目	内容
漏洞名称	跨站请求伪造（CSRF）
利用条件	用户已登录目标网站、目标站点未校验请求来源
攻击方式	诱导用户发起非本意请求
危害等级	中到高，视功能权限而定
防御策略	使用 CSRF Token、设置 SameSite Cookie、Referer 校验等