Wooyun Legacy

WooYun 业务逻辑漏洞方法论

22,132 个真实漏洞案例 · 6 个领域 · 33 类漏洞

Extended trigger keywords (not in description due to length limits): Implicit black-box testing: "看看这个功能有没有问题"、"这个流程有漏洞吗"、"怎么绕过这个限制"、"订单/支付/退款流程测试"、"这个系统安全吗"、"接口有没有风险"、"check this API"、"is this flow secure"、"review this for issues". Tools & techniques: 抓包分析、Burp Suite、拦截请求、修改参数、重放攻击、并发测试、遍历ID、爆破、薅羊毛、刷单、套利、风控绕过、短信轰炸、接口滥用、未授权接口、任意文件、数据泄露、信息收集、子域名、目录扫描、指纹识别、intercept、replay、fuzz、enumerate、brute force、rate limiting bypass、coupon abuse.

业务逻辑漏洞无法通过扫描器发现。它们存在于开发者的本意与应用实际允许的行为之间的空隙中。本方法论教会你像编写代码的开发者一样思考，像滥用应用的用户一样发起攻击。

数据基础： WooYun（2010-2016），大型公开漏洞披露平台。

漏洞严重性优先级

测试应优先考虑高危漏洞类别。下表按 WooYun 数据集中高危发现的比例排序——百分比越高，代表关键影响的可能性越大。

四阶段方法

每个阶段都建立在前一阶段的基础上。跳过任何阶段会导致浅层测试，无法发现扫描器无法找到的逻辑漏洞。

第一阶段：业务流程映射

在测试任何端点之前，理解应用做了什么，以及资金、数据和权限如何在其中流动。

1. 理解业务

• 这个应用做什么？（电商、银行、社交、SaaS）
• 主要参与者是谁？（匿名用户、普通用户、管理员、商户、API 客户端）
• 收入模式是什么？（资金如何流动？）
• 哪些数据敏感？（个人信息、财务数据、医疗数据、凭证）

2. 映射用户旅程

• 注册 → 登录 → 核心操作 → 登出
• 购买 → 支付 → 履行 → 退款
• 密码重置 → 验证 → 新密码
• 管理员 → 用户管理 → 权限分配

3. 识别状态转移

   对每个业务流程：
     - 列出所有状态（待审、活跃、已支付、已发货、已退款）
     - 列出所有有效转移（待审→已支付、已支付→已发货）
     - 问题：能否强制执行无效转移？（待审→已发货）
     - 问题：能否反向转移？（已支付→待审）

4. 映射信任边界

• 客户端 vs 服务器：哪些验证仅在客户端进行？
• 用户 vs 管理员：什么分隔了权限级别？
• 租户 vs 租户：什么防止跨租户访问？
• 内部 vs 外部：哪些假设了受信任的内部来源？

第二阶段：假设形成

使用下面的参考文件形成特定领域的假设。每个领域文件包含详细的攻击模式矩阵、测试清单和防御模式，这些都源自数千个真实的 WooYun 案例。

第一层：领域参考（方法论 + 攻击模式矩阵） — 优先加载

第二层：深度分析手册（技术细节 + 根因分析） — 需要深入某个技术领域时加载

第三层：漏洞案例库（真实案例标题 + 高频 Payload） — 需要引用具体案例或 Payload 模式时加载

渐进加载规则： 先读第一层（领域参考）确定测试方向，再按需读第二层（深度分析）获取技术细节，最后在需要引用具体案例或 Payload 时才读第三层（案例库）。不要一次性加载所有文件。

对每个领域，使用以下结构形成假设：

假设：[业务流程 X] 容易受到 [攻击模式 Y] 的攻击
原因：[来自侦查的证据——参数可见、缺乏服务器验证、ID 可预测]
WooYun 模式：[与领域参考中匹配的模式]
影响：[业务影响——财务损失、数据泄露、账户接管]
测试：[具体的手动测试步骤]

第三阶段：针对性手动测试

业务逻辑需要手动测试，因为漏洞存在于应用如何解释业务规则的方式中，而不是扫描器可以匹配的技术特征。

1. 准备测试账号

• 至少 2 个相同权限级别的账号（用于水平测试）
• 至少每个权限级别 1 个账号（用于垂直测试）
• 记录所有会话令牌、Cookie、ID

2. 执行最小化测试

• 拦截特定请求（Burp/mitmproxy）
• 仅修改要测试的参数
• 观察：服务器是否验证？状态是否改变？
• 记录确切的请求/响应对

3. 根据业务规则分析

• 应用是否在服务器端实施业务规则？
• 状态转移是否可以被强制无序执行？
• 是否可以访问/修改另一个用户的资源？
• 财务价值是否可以被篡改？

4. 如果确认 → 第四阶段 · 如果否定 → 下一个假设 · 如果不确定 → 改变方法

第四阶段：影响评估与文档化

证明业务影响，而不仅仅是技术绕过。

## 发现：[标题]
- 严重级别：[严重/高/中/低]
- 领域：[认证/授权/金融/信息/逻辑/配置]
- WooYun 模式：[此发现匹配的历史模式]
- 业务影响：[财务损失、受影响用户数、数据范围]
- 重现步骤：
  1. [确切的步骤与请求/响应]
  2. [...]
- 补救：[服务器端修复，不是客户端创可贴]

真实案例

这些案例说明为什么业务逻辑测试很重要——每一个都代表 WooYun 研究者发现的真实漏洞：

需要避免的思维陷阱

测试业务逻辑时，要警惕这些导致浅层测试的常见理性化表现：

快速参考

<!-- 数据源：WooYun 漏洞数据库（2016年7月）· 方法论 v2.0 -->

身份认证领域

概述

身份认证漏洞是突破口。8,846 起 WooYun 案例（占所有发现的 40%）证明：大多数应用在第一道防线就已失守。

核心原则： 身份认证是一条链。每一环都必须守住——凭证、会话、重置流程、验证机制。一个薄弱环节 = 完全绕过。

按子域划分的攻击模式

弱凭证（7,513 个案例，58.2% 高危）

铁律：在任何其他身份认证测试之前，先测试默认凭证。WooYun 所有案例中 34% 属于弱密码/默认密码。

系统化测试清单：

阶段 1：默认凭证
- [ ] admin/admin, admin/123456, admin/admin123
- [ ] root/root, root/toor, root/password
- [ ] test/test, guest/guest, demo/demo
- [ ] [厂商名]/[厂商名]（如 tomcat/tomcat）
- [ ] [产品名]/[产品名]
- [ ] 查阅厂商文档中的默认凭证

阶段 2：社会工程学密码
- [ ] 公司名（小写、首字母大写、加年份）
- [ ] 域名（不含顶级域名、加数字）
- [ ] 产品名 + 常见后缀（123, @123, !@#）
- [ ] 城市名 + 年份（beijing2024）
- [ ] 手机号码模式（中国系统常见）

阶段 3：凭证填充攻击
- [ ] 中国 Top 100 密码（123456, a123456, 123456789）
- [ ] 全球 Top 100 密码
- [ ] 行业特定默认密码（医疗、金融、教育）

阶段 4：绕过反暴力破解
- [ ] 验证码重用（同一会话，不刷新）
- [ ] 验证码移除（从请求中删除参数）
- [ ] IP 轮换（X-Forwarded-For 头操纵）
- [ ] 通过响应差异进行账户枚举
- [ ] 通过分布式请求绕过速率限制

关键参数： username, password, account, passwd, pwd, pass

密码重置（777 个案例，88.0% 高危）

在整个 WooYun 数据集中严重性级别最高。每个密码重置流程都存在漏洞。

攻击模式矩阵：

测试流程：

digraph password_reset_test {
    "为账号A请求密码重置" [shape=box];
    "拦截所有流量" [shape=box];
    "令牌在响应中？" [shape=diamond];
    "分析令牌熵" [shape=box];
    "可预测？" [shape=diamond];
    "尝试跳过步骤" [shape=box];
    "用B的标识直接设置密码" [shape=box];
    "将user_id改为账号B" [shape=box];
    "操纵响应" [shape=box];

    "为账号A请求密码重置" -> "拦截所有流量";
    "拦截所有流量" -> "令牌在响应中？";
    "令牌在响应中？" -> "分析令牌熵" [label="是 → 高危"];
    "令牌在响应中？" -> "尝试跳过步骤" [label="否"];
    "分析令牌熵" -> "可预测？";
    "可预测？" -> "将user_id改为账号B" [label="是 → 严重"];
    "尝试跳过步骤" -> "用B的标识直接设置密码";
    "用B的标识直接设置密码" -> "操纵响应";
}

登录绕过（57 个案例，57.9% 高危）

模式：

• 登录表单 SQL 注入：' OR 1=1--
• 默认后门账户（留在生产环境的调试/测试账户）
• 身份认证逻辑反转（检查 if NOT authenticated 而不是 if authenticated）
• Cookie/令牌伪造（签名弱，无验证）
• OAuth 错误配置（redirect_uri 操纵、state 参数缺失）

验证码/验证绕过（384 个案例，44% 高危）

系统化验证码绕过：

真实案例

防御模式（来自 WooYun 修复数据）

代码层面

• 密码：bcrypt(cost≥12)，绝不使用 MD5/SHA1
• 密码复杂度：最少 8 个字符 + 大小写 + 数字 + 特殊字符
• 密码历史：拒绝重用最近 3 个密码
• 首次登录强制修改密码
• 会话：密码学随机，HttpOnly，Secure，SameSite
• 重置令牌：≥32 字节随机，单次使用，时间限制（15 分钟）
• 验证码：服务器端验证，单次使用，绑定到会话

架构层面

• 集中式身份认证（SSO/OAuth2/SAML）
• 对所有特权操作启用 MFA
• 账户锁定：5 次连续失败后锁定，逐步延迟（1秒、2秒、4秒、8秒...）
• 速率限制：按账户和按 IP 分别限制
• 地理异常告警：从新位置登录时通知

监控

• 登录失败激增检测（每个账户超过 5 次/分钟）
• 凭证填充攻击检测（多个账户，每个尝试次数少）
• 密码重置异常（来自单个 IP 的批量重置）
• 地理异常（来自新国家的登录）

授权域

概述

授权漏洞允许已认证用户访问他们不应该访问的资源。6,269 个 WooYun 案例证明：开发者构建了身份认证但忽视了授权控制。

核心原则： 身份认证回答"你是谁？"授权回答"你能做什么？"大多数应用在第一个问题上表现不错，但在第二个问题上表现糟糕。

攻击模式分类

digraph authz_taxonomy {
    "授权漏洞" [shape=box style=filled fillcolor=lightyellow];
    "水平越权" [shape=box label="水平越权\n(同级权限)"];
    "垂直越权" [shape=box label="垂直越权\n(低级→高级权限)"];
    "缺失认证" [shape=box label="缺失认证\n(完全无认证检查)"];

    "授权漏洞" -> "水平越权" [label="IDOR\n越权"];
    "授权漏洞" -> "垂直越权" [label="权限提升"];
    "授权漏洞" -> "缺失认证" [label="未授权访问"];
}

水平权限绕过 / IDOR（1,705+230 个案例）

最容易被忽视的漏洞类型。扫描器无法发现。

系统化测试协议：

对于每个返回用户特定数据的 API 端点：

1. 识别资源标识符
   - URL 路径：/api/users/{id}/orders
   - 查询参数：/api/orders?user_id=123
   - POST 请求体：{"user_id": 123, "action": "view"}
   - Cookie/头：X-User-Id: 123

2. 准备两个测试账号（账号 A，账号 B）
   - 以 A 身份登录，记录所有标识符
   - 以 B 身份登录，记录所有标识符

3. 测试每项 CRUD 操作
   - [ ] 创建：A 能否创建 B 拥有的资源？
   - [ ] 读取：A 能否查看 B 的资源？（最常见）
   - [ ] 更新：A 能否修改 B 的资源？
   - [ ] 删除：A 能否删除 B 的资源？

4. 测试标识符操纵
   - [ ] 直接 ID 替换：123 → 124
   - [ ] ID 枚举：遍历 ID 范围
   - [ ] 参数污染：?uid=123&uid=456（服务器取最后一个）
   - [ ] 数组注入：uid[]=123（绕过类型检查）
   - [ ] JSON 嵌套：{"user": {"id": 456}}
   - [ ] 编码 ID：base64(456)、hex(456)
   - [ ] 负数/零 ID：id=0、id=-1
   - [ ] UUID 预测（如果使用了顺序 UUID）

关键参数： user_id, uid, id, order_id, file_id, account_id, tenant_id, doc_id, msg_id

WooYun 案例模式： "北京现代某平台可越权遍历所有用户上传证件（几百万身份证件/行驶证件/发票/驾驶证）" — 顺序文件 ID 且无所有权检查。

垂直权限 / 权限提升（255+86 个案例）

测试协议：

1. 识别权限级别
   - 匿名 → 已注册用户 → 管理员 → 超级管理员
   - 用户角色：买家、卖家、代理人、经理

2. 映射仅限管理员的端点
   - /admin/*, /api/admin/*, /manage/*
   - 用户管理、配置、报告
   - 识别来源：JavaScript 文件、API 文档、网站地图、robots.txt

3. 用低权限会话测试
   - [ ] 用用户令牌访问管理员端点
   - [ ] 添加管理员参数：role=admin, is_admin=true, level=9
   - [ ] 在注册时修改角色：{"role": "admin"}
   - [ ] 完全不带令牌访问管理员 API
   - [ ] 改变 HTTP 方法：GET→POST、POST→PUT

未授权访问 / 缺失身份认证（2,102+1,891 个案例）

最基本的漏洞：完全没有身份认证的端点。

系统化端点发现：

测试：

对于每个发现的端点：
1. 不带任何身份认证头/Cookie 访问
2. 如果重定向到登录 → 尝试添加 X-Forwarded-For: 127.0.0.1
3. 如果 403 → 尝试替代 HTTP 方法（GET/POST/PUT/DELETE/PATCH）
4. 如果 403 → 尝试路径规范化：/admin/ vs /admin vs /Admin
5. 如果 403 → 尝试 URL 编码：/%61dmin
6. 记录：哪些端点完全没有身份认证？

WooYun 模式： 58.2% 的未授权访问发现 = 管理后台完全暴露在互联网上。

任意操作 / 任意X（529 个案例，51-86% 高危）

"权限维度"— 攻击者在任何对象上都不应该执行的操作。

此类别不同于 IDOR。IDOR 是关于访问"他人的"资源。任意操作是关于执行"你不应该有的操作"——无论资源属于谁。

测试协议：

对于每个写入/删除/管理员操作：

1. 识别权限模型
   - 谁应该被允许执行此操作？
   - 检查是在用户级别、角色级别还是对象级别？

2. 测试权限绕过
   - [ ] 以无特权用户身份执行操作
   - [ ] 对非当前用户拥有的对象执行操作
   - [ ] 执行批量操作（通过 API 枚举修改/删除全部）
   - [ ] 以普通用户身份执行仅限管理员的操作（批准、发布）
   - [ ] 自我批准：创建请求 + 批准自己的请求

3. 测试注册控制
   - [ ] 当注册"关闭"或"仅邀请"时注册
   - [ ] 以管理员/提升的角色注册
   - [ ] 绕过电子邮件域名限制
   - [ ] 绕过注册的电话验证

真实案例

防御模式

代码层面

• 默认拒绝： 将公开端点加入白名单，其他一切都需要身份认证
• 所有权验证： 在每个查询上验证 resource.owner_id == current_user.id
• ORM 级别过滤： Model.where(user_id: current_user.id) — 永不使用原始 ID
• 不可预测的 ID： UUID v4，而非顺序整数
• RBAC/ABAC： 基于角色或属性的访问控制框架
• 职能分离： 创建者不能批准自己的请求

架构层面

• API 网关： 集中式授权执行点
• 零信任： 验证每个请求，无论其网络来源
• 多租户隔离： 数据库级别的 tenant_id 过滤
• URL 模式保护： 框架级别的路由授权（Spring Security、Django 权限）

监控

• 跨用户访问模式： 用户 A 访问许多其他用户的资源
• 管理员端点访问： 非管理员 IP 访问 /admin/*
• ID 枚举检测： 来自单个会话的顺序 ID 请求
• 权限变更审计： 所有角色/权限修改已记录
• 批量操作检测： 单个用户修改/删除异常数量的记录

配置域

概述

配置不当是最容易得手的漏洞。1,796 个 WooYun 案例中 72.6% 为高危，证明：最具破坏力的入侵来自默认配置。

核心原则： 每个服务的默认配置都是为了便利而非安全设计的。如果你没有明确加固，就存在漏洞。

攻击模式矩阵

默认凭证（参考弱口令交叉引用）

服务特定的默认凭证数据库：

暴露的管理界面

系统性发现：

1. Web 管理控制台
   - [ ] /manager/html (Tomcat)
   - [ ] /jmx-console (JBoss)
   - [ ] /console (WebLogic, H2, Rails)
   - [ ] /admin（通用）
   - [ ] /jenkins
   - [ ] /zabbix
   - [ ] /grafana
   - [ ] /solr/admin
   - [ ] /nacos
   - [ ] /actuator (Spring Boot)
   - [ ] /druid (阿里巴巴 Druid)

2. 数据库管理
   - [ ] :3306 (MySQL，无密码)
   - [ ] :6379 (Redis，无认证)
   - [ ] :27017 (MongoDB，无认证)
   - [ ] :9200 (Elasticsearch，无认证)
   - [ ] :5432 (PostgreSQL，信任认证)
   - [ ] /phpmyadmin, /pma, /myadmin

3. 部署/CI 工具
   - [ ] :2375 (Docker Remote API，无 TLS)
   - [ ] :8080 (Jenkins，无认证)
   - [ ] :8443 (Kubernetes Dashboard)
   - [ ] :9000 (Portainer, SonarQube)
   - [ ] :8161 (ActiveMQ)
   - [ ] :15672 (RabbitMQ)

4. 监控/调试
   - [ ] /server-status (Apache)
   - [ ] /nginx_status (Nginx)
   - [ ] /debug/pprof (Go)
   - [ ] /actuator/env (Spring，泄露环境变量)
   - [ ] /actuator/heapdump (Spring，泄露内存)
   - [ ] /trace（暴露请求历史）

配置不当的服务

高影响配置不当模式：

云配置不当（新兴模式，WooYun 时代后）

基于现代部署模式的补充：

1. 存储
   - [ ] S3 存储桶公开读/写
   - [ ] Azure Blob 容器匿名访问
   - [ ] GCS 存储桶 allUsers 权限
   - [ ] OSS（阿里云）存储桶 ACL 配置不当

2. 计算
   - [ ] IMDS v1 可访问（无需令牌）
   - [ ] 安全组允许 0.0.0.0/0 访问管理端口
   - [ ] 禁用 SSH 密钥认证，启用密码认证
   - [ ] 用户数据脚本包含凭据

3. IAM
   - [ ] 通配符权限（Action: "*", Resource: "*"）
   - [ ] 跨账户角色信任过于宽松
   - [ ] 服务账户密钥暴露在代码/配置中
   - [ ] 根/管理员账户未启用 MFA

测试协议

digraph config_test {
    "识别所有服务" [shape=box];
    "检查默认凭证" [shape=box];
    "默认凭证有效？" [shape=diamond];
    "检查暴露的端点" [shape=box];
    "有暴露？" [shape=diamond];
    "检查服务配置" [shape=box];
    "发现配置不当？" [shape=diamond];
    "记录发现" [shape=box];
    "进入其他领域" [shape=box];

    "识别所有服务" -> "检查默认凭证";
    "检查默认凭证" -> "默认凭证有效？";
    "默认凭证有效？" -> "记录发现" [label="是 → 严重"];
    "默认凭证有效？" -> "检查暴露的端点" [label="否"];
    "检查暴露的端点" -> "有暴露？";
    "有暴露？" -> "记录发现" [label="是 → 高危"];
    "有暴露？" -> "检查服务配置" [label="否"];
    "检查服务配置" -> "发现配置不当？";
    "发现配置不当？" -> "记录发现" [label="是"];
    "发现配置不当？" -> "进入其他领域" [label="否"];
    "记录发现" -> "进入其他领域";
}

真实案例

防御模式

代码层面

• 部署前更改所有默认凭证
• 禁用不必要的功能： 调试模式、目录列表、TRACE 方法
• 最小权限原则： 服务账户仅具有最低必需权限
• 配置即代码： 版本控制、审查配置更改

架构层面

• 网络隔离： 管理界面仅在内网
• 防火墙规则： 对管理端口仅允许白名单访问
• 反向代理： 永远不要直接暴露后端服务
• 密钥管理： 使用 Vault/KMS 存储凭证，而非配置文件

监控

• 默认凭证扫描： 自动检查已知默认凭证
• 暴露服务检测： 定期外部扫描开放的管理端口
• 配置漂移： 对未授权的配置更改发出警报
• 新服务检测： 对新增监听端口/服务发出警报

金融领域

概述

金融逻辑漏洞导致直接经济损失。2,919 个 WooYun 案例中 68-83% 为高危，证明：与金钱相关的逻辑始终是最容易被利用的。

核心原则： 客户端请求中出现的任何财务数值都是一个待验证的假设。价格、数量、折扣、余额、手续费——如果客户端发送了它，客户端就可以修改它。

金融测试铁律

绝不信任客户端财务计算。
如果服务器接受来自客户端的价格/金额/数量 → 就认为它易受攻击，除非经过验证。

攻击模式矩阵

支付篡改（1,056 个案例，68.7% 高危）

系统性支付测试检查清单：

1. 价格篡改
   - [ ] 修改金额为 0.01（最小被接受金额）
   - [ ] 修改金额为 0（零成本购买）
   - [ ] 修改金额为负数（退款给攻击者）
   - [ ] 修改金额为非常大的负数（溢出）
   - [ ] 如果支持多币种则修改货币代码
   - [ ] 分别修改单价与总价

2. 数量篡改
   - [ ] 数量设为 0（免费商品）
   - [ ] 数量设为 -1（负数购买 = 退款）
   - [ ] 数量设为非常大的数字（整数溢出）
   - [ ] 数量设为小数（0.001 件）
   - [ ] 设置数量与价格所暗示的不同

3. 折扣/优惠券滥用
   - [ ] 重复应用同一优惠券
   - [ ] 对已打折商品应用优惠券
   - [ ] 在请求中修改折扣百分比（discount=100）
   - [ ] 使用过期优惠券（重放有效请求）
   - [ ] 使用针对不同产品类别的优惠券
   - [ ] 堆叠多个促销类型

4. 竞态条件（Turbo Intruder / 并发请求）
   - [ ] 双花：同时提交两次支付
   - [ ] 优惠券竞速：并行应用同一单次使用优惠券
   - [ ] 余额竞速：并发提取相同余额
   - [ ] 库存竞速：并行购买最后一件商品

5. 状态机绕过
   - [ ] 跳过支付步骤：从购物车直接跳到订单确认
   - [ ] 修改订单状态：将 status=pending 改为 status=paid
   - [ ] 对不同订单重放成功的支付回调
   - [ ] 在支付后但履行前修改订单

关键参数： amount, price, total, quantity, discount, coupon_code, currency, fee, status, order_id, payment_id

订单篡改（1,227 个案例，74.2% 高危）

订单状态机攻击：

预期流程：
  购物车 → 待支付 → 已支付 → 处理中 → 已发货 → 已送达 → 已完成

攻击向量：
  购物车 → 已完成（完全跳过支付）
  已支付 → 购物车（恢复以在支付后修改项目）
  已发货 → 已支付（恢复以获得退款且保留商品）
  任意 → 已取消 + 退款（收到商品后取消）

测试协议：

对每个状态转换：
1. 捕获触发转换的请求
2. 能否按错误的顺序触发？
3. 能否对不同用户的订单触发？
4. 能否多次触发？
5. 能否在状态之间修改订单内容？

余额/提现（113+59 个案例，77-83% 高危）

关键模式：

定价/充值（218+176+70 个案例）

价格篡改模式：

1. 充值漏洞利用
   - [ ] 在请求中修改充值金额
   - [ ] 重放成功的充值回调
   - [ ] 使用测试支付网关凭证
   - [ ] 在服务器接收前修改支付网关响应

2. 价格不一致
   - [ ] 购物车、结账、支付中的不同价格
   - [ ] 将 item_id 修改为相同数量的更便宜产品
   - [ ] 在价格计算后向购物车添加商品
   - [ ] 币种混淆（¥1 vs $1 vs 1 积分）

竞态条件测试指南

金融竞态条件需要特殊技术：

# 并发支付测试的概念性方法
# 使用 Burp Turbo Intruder 或自定义脚本

# 第1步：准备请求（如提现）
# 第2步：同时发送 N 个相同请求
# 第3步：检查：服务器是否处理了多个？

# 漏洞指标：
# - 余额减少了 N × 金额（应该是 1 × 金额）
# - 单次使用操作的多个成功响应
# - 创建了多个交易记录

工具： Burp Turbo Intruder、自定义 Python 线程脚本、使用 & 后台运行的 curl

真实案例

防御模式

代码层面

• 仅服务器端计算： 价格 = 数据库价格 × 数量，绝不来自客户端
• 幂等键： 唯一交易 ID，拒绝重复
• 乐观锁： UPDATE balance SET amount=amount-X WHERE amount >= X（原子操作）
• 状态机执行： 严格的有限状态机及有效转换白名单
• 签名验证： 支付回调必须验证密码签名

架构层面

• 分布式锁： 用于金融操作的 Redis SETNX / Zookeeper
• 消息队列： 具有恰好一次语义的异步支付处理
• 两阶段提交： 扣款 → 验证 → 履行，任何失败时回滚
• 对账： 与支付网关的自动日对账

监控

• 异常金额： 金额 ≤ 0.01 的订单
• 高频率： 每个用户每分钟多个订单/提现
• 状态异常： 未经"已支付"状态直接达到"已完成"的订单
• 余额不一致： 实时余额与交易总和不匹配

信息泄露领域

概述

信息泄露是催化剂。6,446 个 WooYun 案例证明：暴露的信息能够启动所有其他攻击类型——泄露的凭据导致账户接管，泄露的架构导致精准利用。

核心原则： 应用程序暴露的任何超出用户需求的信息都是漏洞。调试信息、堆栈跟踪、内部 IP、API 密钥、源代码——每一项都是攻击面倍增器。

攻击模式矩阵

源代码/配置泄露（4,858 个案例，64.7% 高危）

系统性发现检查清单：

1. 版本控制泄露
   - [ ] /.git/config → 通过 GitHack/git-dumper 克隆
   - [ ] /.svn/entries → SVN 仓库暴露
   - [ ] /.hg/ → Mercurial 仓库
   - [ ] /.bzr/ → Bazaar 仓库
   - [ ] /CVS/Root → CVS 仓库

2. 备份文件
   - [ ] /backup.zip, /backup.tar.gz, /backup.sql
   - [ ] /db.sql, /database.sql, /dump.sql
   - [ ] /web.rar, /www.zip, /site.tar.gz
   - [ ] /[域名].zip, /[域名].sql
   - [ ] /*.bak, /*.old, /*.orig, /*.swp
   - [ ] /WEB-INF/web.xml (Java)
   - [ ] /config.php.bak, /settings.py.bak

3. 调试/测试端点
   - [ ] ?debug=true, ?debug=1, ?test=1
   - [ ] /debug, /test, /phpinfo.php
   - [ ] /actuator (Spring Boot), /metrics, /health, /env
   - [ ] /trace, /dump, /heapdump
   - [ ] /__debug__/ (Django 调试工具栏)
   - [ ] /console (Rails 控制台, H2 控制台)
   - [ ] /swagger-ui.html, /api-docs, /openapi.json

4. 错误信息
   - [ ] 触发 500 错误 → 包含文件路径的堆栈跟踪
   - [ ] 无效输入 → 包含查询结构的数据库错误
   - [ ] 缺少参数 → 包含类名的框架错误
   - [ ] 404 响应头中暴露服务器版本

敏感数据泄露（1,588 个案例，62.8% 高危）

个人信息泄露模式：

关键发现指标：

• API 响应字段数 > UI 可见字段数
• 生产环境中的详细错误消息
• 暴露版本的服务器头（X-Powered-By、Server）
• HTML/JS 中暴露内部信息的注释
• 客户端 JavaScript 中的凭据

目录/文件枚举

高收益路径（来自 WooYun 统计）：

# 管理
/admin/            /manage/           /backend/
/administrator/    /system/           /console/

# 配置
/config/           /conf/             /settings/
/.env              /wp-config.php     /application.yml

# 数据
/upload/           /uploads/          /files/
/data/             /export/           /tmp/

# 监控
/status/           /server-status     /server-info
/monitoring/       /metrics/          /grafana/

# 文档
/api/docs          /swagger/          /redoc/
/readme.md         /README.txt        /CHANGELOG

真实案例

防御模式

代码层面

• 最小化响应： 仅返回客户端需要的字段，不返回完整数据库对象
• 错误处理： 生产环境仅显示通用错误消息，详细信息仅在开发环境
• 凭据管理： 使用环境变量或密钥库，绝不在代码/配置文件中
• 日志脱敏： 在日志中掩盖个人信息（邮箱示例：a***@example.com）

架构层面

• 强制执行 .gitignore： 配置文件、.env、凭据绝不在仓库中
• WAF 规则： 阻止访问 /.git、/.svn、/.env、/backup*
• 响应头加固： 删除 Server、X-Powered-By、X-AspNet-Version
• CDN 配置： 不缓存已认证的响应

监控

• 敏感路径访问： 外部 IP 访问 /.git、/.env、/admin 时告警
• 批量数据访问： 大型 API 响应或高频数据请求时告警
• 错误率监控： 500 错误激增 = 可能的侦察
• 凭据泄露扫描： 监控 GitHub/GitLab/Pastebin 上泄露的凭据

业务逻辑领域

概述

业务逻辑缺陷最难发现也最难修复。1,679 个 WooYun 案例证明：当状态机错误时，建立在它之上的每个功能都继承这个缺陷。

核心原则： 每个多步骤业务流程都是一个状态机。如果能在不满足前置条件的情况下到达某个状态，则状态机被破坏。

攻击模式矩阵

状态机绕过（1,391 个案例，65.3% 高危）

基础测试：

对于每个多步骤流程：

1. 映射预期状态序列
   第1步（前置条件：无）→ 第2步（前置条件：第1步完成）→ 第3步 ...

2. 独立测试每个步骤
   - 能否在不完成第2步的情况下到达第3步？
   - 能否在完成第3步后返回第1步？
   - 能否多次重复第2步？
   - 能否在第3步时修改第1步提交的数据？

3. 识别执行机制
   - 客户端 JavaScript 流程？（绕过：直接请求第 N 步端点）
   - 基于会话的状态？（绕过：操纵会话、使用不同会话）
   - 基于令牌的状态？（绕过：预测/重用令牌）
   - 服务器端状态机？（测试：转换逻辑中的边界情况）

常见易受攻击的流程：

竞态条件 / TOCTOU（266 个案例，74.8% 高危）

业务逻辑中的检查时间到使用时间缺陷：

模式：
  线程A：检查余额(100) → 足够 → 扣款(100) → 余额 = 0
  线程B：检查余额(100) → 足够 → 扣款(100) → 余额 = -100

  结果：从 100 的余额中提取了 200

测试方法：

1. 识别具有检查-行动模式的操作
   - 余额检查 → 提现
   - 库存检查 → 购买
   - 优惠券有效性检查 → 应用优惠券
   - 推荐检查 → 奖励积分

2. 准备竞态条件测试
   - 捕获完整请求
   - 设置 N 个并发相同请求（N = 5-20）
   - 工具：Burp Turbo Intruder、Python 线程、使用 & 后台运行的 curl

3. 执行
   - 同时发送所有 N 个请求
   - 观察：有多少个成功？
   - 预期：仅 1 个应该成功
   - 存在漏洞：多个成功

4. 验证
   - 检查最终状态（余额、库存、优惠券使用次数）
   - 计算：检查-行动是否是原子的？

业务规则绕过（266+22 个案例）

利用业务规则中假设的模式：

设计缺陷作为攻击面（1,391 个案例）

WooYun "设计缺陷" 类别中的结构模式：

1. 客户端信任
   - 服务器信任客户端提供的：价格、角色、user_id、权限级别
   - 测试：修改影响业务逻辑的每个参数

2. 隐式授权
   - "如果用户到达此页面，他们必定被授权"
   - 测试：直接 URL 访问、不通过 UI 工作流的 API 调用

3. 验证不一致
   - 前端验证，后端不验证
   - 测试：绕过前端（curl、Burp），直接提交到 API

4. 可预测的令牌/ID
   - 顺序订单 ID、基于时间戳的令牌
   - 测试：分析模式，预测下一个值

5. 缺少原子性
   - 多步骤操作未包装在事务中
   - 测试：中断操作，检查部分状态

决策流程图：哪种逻辑缺陷？

digraph logic_decision {
    "多步骤流程？" [shape=diamond];
    "金融操作？" [shape=diamond];
    "共享资源？" [shape=diamond];
    "客户端逻辑？" [shape=diamond];
    "状态机绕过" [shape=box style=filled fillcolor="#ffcccc"];
    "竞态条件" [shape=box style=filled fillcolor="#ffcccc"];
    "业务规则绕过" [shape=box style=filled fillcolor="#ffffcc"];
    "设计缺陷" [shape=box style=filled fillcolor="#ffffcc"];

    "多步骤流程？" -> "状态机绕过" [label="是，测试步骤跳过"];
    "多步骤流程？" -> "金融操作？" [label="同时检查"];
    "金融操作？" -> "竞态条件" [label="是，测试并发"];
    "金融操作？" -> "共享资源？" [label="同时检查"];
    "共享资源？" -> "竞态条件" [label="是，TOCTOU"];
    "共享资源？" -> "客户端逻辑？" [label="同时检查"];
    "客户端逻辑？" -> "设计缺陷" [label="是，绕过客户端"];
    "客户端逻辑？" -> "业务规则绕过" [label="测试边界情况"];
}

真实案例

防御模式

代码层面

• 服务器端状态机： 用显式有限状态机强制执行有效转换
• 原子操作： 具有适当隔离级别的数据库事务
• 乐观锁： 记录上的版本字段，拒绝过时更新
• 幂等性： 唯一请求 ID，拒绝重复操作
• 输入验证： 服务器端、类型安全、范围检查

架构层面

• 分布式锁： Redis/Zookeeper 用于并发访问控制
• 事件溯源： 所有状态转换的不可变审计跟踪
• Saga 模式： 分布式操作的补偿事务
• 断路器： 防止多服务流中的级联故障

监控

• 状态转换异常： 订单到达无效状态
• 并发操作激增： 毫秒内的多个相同请求
• 值异常： 负数、零价格、极端数量
• 跨渠道不一致： 不同客户端执行相同操作的结果不同