漏洞解析--CSRF

漏洞原理

核心

CSRF（跨站请求伪造）漏洞的核心在于：浏览器会在跨站请求中自动附带用户的 Cookie 等身份凭证，导致攻击者可以诱导用户在已登录的情况下对目标网站发起恶意请求。

原理详解

1. 用户登录了 B 网站，B 网站在浏览器里设置了会话 Cookie。

2. 用户在未退出登录的情况下访问了攻击者控制的 A 网站。

3. A 网站页面中包含一个指向 B 网站的恶意请求，例如：

   <img src="https://b.com/transfer?to=attacker&amount=1000">
   

上述链接会向攻击者转账1000元
4. 浏览器在请求 B 网站时，会自动带上用户的 Cookie。
5. B 网站无法区分这是用户主动操作还是被攻击者诱导的请求，于是执行了恶意操作。

---

检测方法与危害

检测方法

1. 手工检测方法

步骤一：准备测试环境

• 使用测试账号登录目标网站。
• 打开浏览器开发者工具，记录敏感请求（如修改密码、转账、删除等）。

步骤二：构造恶意请求

• 将敏感请求封装成 HTML/JS 片段，模拟攻击者网站。例如：

<!-- 自动发起 GET 请求 -->
<img src="https://target.com/transfer?to=attacker&amount=1000"><!-- 或自动提交表单 POST 请求 -->
<form action="https://target.com/change_email" method="POST" id="csrfForm"><input type="hidden" name="email" value="attacker@example.com">
</form>
<script>document.getElementById('csrfForm').submit();</script>

步骤三：访问恶意页面

• 在已登录状态下访问构造好的页面。

• 观察目标站点是否执行了请求：

  • 成功执行 → 存在 CSRF 漏洞
  • 被拒绝或需要 Token → 可能已防护

---

2. 自动化检测方法

2.1 使用漏洞扫描器

• 工具如 OWASP ZAP、Burp Suite 都能检测 CSRF：

  • Burp Suite 的 “CSRF Scanner” 可以自动检测表单、请求是否缺少 CSRF Token。
  • ZAP 的 “Active Scan” 同样支持 CSRF 检测。

2.2 检测原理

• 扫描器会：

  1. 捕获所有敏感请求。
  2. 重放请求到目标站点，模拟跨站攻击。
  3. 检查请求是否被执行（例如账户信息修改成功）。

危害

只要是用户在正常登录状态下能做到的操作，CSRF 理论上都能做到。

---

修复方法

推荐使用 Authorization: Bearer 的认证方式（JWT/OAuth），避免浏览器自动带 Cookie，从根本上杜绝 CSRF。下面是两种常见修复方法。

Refer头

不应作为主流修复方法。虽然实现简单，但是Referer不可靠，Referer段可能被浏览器去掉，也不利于用户隐私保护。

• 原理：通过检查 Referer 或 Origin 请求头，验证请求是否来自本站页面。

Token机制

可以作为主流修复方法

• 原理：在表单或请求中加入一个随机生成的 CSRF Token，并在服务端校验。
• 流程：
  1. 用户访问页面时，服务器生成一个随机 Token，放到前端localStorage、sessionStorage 或内存里。
  2. 前端在提交请求时，必须通过被访问网站的前端js脚本显式带上该 Token。
  3. 服务器验证 Token 是否正确。
  4. 因为用户是通过其他网站（网站A）访问一个网站（称为网站B），而只有网站B中的前端脚本中存储token，以此通过A网站无法获取B网站脚本中存储的token。

补充说明

Token和Cookie对比

特性	Cookie	Token
发送方式	浏览器自动附带（不可控）	前端代码显式添加（可控）
存储位置	浏览器 Cookie Jar	localStorage / sessionStorage / 内存
安全风险	易受 CSRF 攻击	抵抗 CSRF，但需防 XSS
使用场景	传统网站 Session 管理	API / 前后端分离 / 移动端
防御手段	需额外加 CSRF Token、SameSite Cookie	本身天然抵御 CSRF

localStorage/sessionStorage/内存

1. localStorage

浏览器提供的存储空间，存放在用户本地硬盘上。

特点：

• 持久存储（浏览器关了再开还在）。

• 同源限制：只能被同一个域名的前端 JS 访问。

• 常用于保存长期有效的 Token（例如 JWT）。

举例：

localStorage.setItem("token", "eyJhbGciOi...");
console.log(localStorage.getItem("token"));

2. sessionStorage

和 localStorage 类似，也是浏览器提供的存储空间。

特点：

• 仅在当前浏览器标签页有效。

• 关闭标签页后就会清除。

• 常用于保存短期 Token（例如一次性登录票据）。

举例：

sessionStorage.setItem("token", "eyJhbGciOi...");
console.log(sessionStorage.getItem("token"));

3. 内存存储（In-memory）
   特点：

• 不依赖浏览器自带的存储机制，而是把 Token 直接保存在运行时变量里。

• 一旦页面刷新或浏览器关闭，变量就会消失。

• 常用于安全要求更高的场景，因为 Token 不会长期暴露在 localStorage / sessionStorage 中。

举例：

let token = "eyJhbGciOi...";  // 保存在 JS 变量里