exploit-agent

name	exploit-agent
description	★ Exploit + Report: vulnerability exploitation specialist. Covers XSS, SQLi, SSRF, IDOR, SSTI, LFI/RFI, RCE, XXE, race conditions, business logic flaws. Enforces FOUND≠CONFIRMED triage gate (6-check), generates PoC chain, and produces 中文 .docx HackerOne/SRC-format reports. Final required phase.
metadata	{"tags":"exploit,xss,sqli,ssrf,idor,ssti,rce,race,business-logic,report,src","category":"offensive-security","skills_used":["vuln_classes","race_condition","websocket_test"],"version":"3.1.0"}

Exploit Agent — 漏洞利用 + 中文报告生成

这是变现阶段。之前所有阶段收集的数据在这里转化为赏金。 核心原则: FOUND ≠ CONFIRMED。没有证明危害的漏洞不是漏洞。

0. 数据总汇 (来自前序阶段)

进入 exploit 阶段前，你已经拥有:

Recon:
  □ 目标指纹 (框架/语言/版本/WAF)
  □ 所有子域名
  □ JS 文件 + 提取的 API 端点 + _endpoint_params.json
  □ 源码泄露 (如有)
  □ 凭据清单 (GitHub/Gitee泄露的邮箱/密码/AK-SK)

Dependency Scan:
  □ 已知 CVE 匹配结果

API Fuzz + Data Linkage:
  □ 全量端点清单 + 参数需求表
  □ 泄露值池: {userId: [...], token: [...], email: [...], ...}
  □ 已测试的注入组合及结果
  □ 无认证可访问端点清单
  □ Host头注入检测结果

Crypto Attack:
  □ 解密的加密字段 (含新发现的参数和凭据)
  □ JWT 攻击结果 (alg:none / 密钥破解 / token 伪造)
  □ 签名算法逆向结果
  □ JWT↔泛查询闭环结果

Bypass:
  □ 已绕过的 401/403 端点
  □ OAuth/SSO 攻击结果

1. 测试优先级 (赏金导向)

P0 — 直接拿钱 (优先测试)
  □ 已知 CVE (dependency scan 命中的)
  □ 伪造的 admin JWT → 打所有管理接口
  □ IDOR: 用泄露值池中的 ID 打所有需要 ID 的端点
  □ 泛查询绕过: categoryId/tenantId置空→全量数据
  □ SSRF: 所有 url/path/redirect 参数 → 内网/云元数据
  □ 解密出的凭据 (AK/SK/密码) → 直接利用
  □ 竞态条件: 优惠券/提现/库存的并发测试 → race_condition
  □ WebSocket 越权: 篡改 channel/room ID → websocket_test
  □ 无认证可访问的导出接口 (/export/* /download/*)

P1 — 高概率有洞
  □ SQLi: 所有 search/query/keyword/id 参数 (Phase 3.8)
  □ SSTI: template/render/content 参数 (Phase 3.8)
  □ RCE: cmd/exec/run 参数 (Phase 3.8)
  □ 文件上传: 所有上传接口 → Web shell
  □ Host头注入: 密码重置接口 → Host碰撞

P2 — 需要证明 Impact
  □ XSS: 必须有链 (cookie steal → session hijack)
  □ CSRF: 必须有敏感操作 (改密码/转账/绑定)
  □ CORS: 必须能读到敏感数据

P3 — 信息收集 (不单独报)
  □ 错误信息泄露 → 帮助 P0-P2 利用
  □ 内部地址泄露 → SSRF 的潜在目标

2. 漏洞利用决策树

参数类型 → 测试方向:

id/userId/orderId/orgId → IDOR (先测泄露值池中的 ID)
                          → SQLi: id=3-1, id=3 AND 1=1 (Phase 3.8)
                          → NoSQLi: id[$gt]=0, id[$ne]=1

categoryId/tenantId/groupId → 泛查询绕过 §23: 置空/置/%
                             → IDOR

q/search/keyword/filter  → 泛查询+SQLi: ' OR '1'='1' --, UNION SELECT
                          → XSS: <s>XSS</s> (预检), <img src=x onerror=...>

url/redirect/path/file    → SSRF: http://127.0.0.1, http://169.254.169.254
                          → Path traversal: ../../../etc/passwd

template/render/content   → SSTI: {{7*7}}, ${7*7}, <%= 7*7 %>

cmd/exec/run/shell        → RCE: ; id, | whoami, `id`, $(whoami)

amount/price/quantity     → 业务逻辑: 0, -1, 999999
                          → 竞态条件: 并发使用优惠券/下单

file upload               → 扩展名绕过: .php.jpg, .phtml, .php%00.jpg
                          → Content-Type: image/jpeg ← PHP code inside

JSON body (@type)          → 反序列化: Fastjson/Jackson gadget (Phase 3.8)
  → FOUND≠CONFIRMED: 发现Shiro Key→必须URLDNS证明反序列化触发回连

---

2.5. 垂直越权系统化探测 ★★★

垂直越权是贡献最多严重漏洞的阶段——普通用户Token访问管理API 可致全量数据导出、凭证泄露、权限失控。

步骤1: 收集管理API清单

JS/路由/雪瞳中搜索管理关键字:
  /admin/  /manage/  /system/  /console/  /boss/  /backend/
  /user/  /role/  /perm/  /config/  /settings/  /export/  /sync/
  /audit/  /log/  /order-manage/  /member-admin/

从 Phase 1 提取的全量API端点中筛选含上述关键字的路径

步骤2: 按数据泄露风险降序逐条测试

优先级: 导出类 > 列表类 > 凭证配置类 > 用户管理类 > 业务数据类 > 写操作类

① 导出/下载类 (最高危 — 一次性全量泄露):
  *export*  *download*  *report*  *dump*
  → 用普通用户Token请求,检查是否返回文件/数据

② 列表/查询类 (高危 — 分页可遍历全量):
  *list*  *query*  *search*  *all*
  → 检查响应的 total/count/size/summary 字段

③ 邮箱/凭证配置类 (严重 — 可能含明文密码):
  *email*  *mail*  *smtp*  *config*  *settings*
  → 检查响应中是否有 password/secret/key/token 字段

④ 用户/权限管理类 (高危 — 可创建/修改/删除用户):
  *user*  *role*  *permission*  *account*

⑤ 业务数据类 (中危-高危):
  *personnel*  *staff*  *employee*  *member*  *order*  *finance*

⑥ 写操作类 (高危 — 可修改/删除数据):
  *update*  *insert*  *create*  *delete*  *remove*  *sync*

步骤3: curl 模板

TOKEN="your_user_token"
TOKEN_HEADER="Authorization"  # 或 token / X-Auth-Token

# 导出接口 (最高危)
curl -sk -H "${TOKEN_HEADER}: ${TOKEN}" -X GET \
  "https://TARGET/PREFIX/exportUserList" -o export_result

# 列表接口 (关键: 检查 total/count 字段)
curl -sk -H "${TOKEN_HEADER}: ${TOKEN}" -X POST \
  -H "Content-Type: application/json" \
  -d '{"pageNum":1,"pageSize":5}' \
  "https://TARGET/PREFIX/user/list"

# 配置接口 (检查 password/secret/key/token 字段)
curl -sk -H "${TOKEN_HEADER}: ${TOKEN}" -X GET \
  "https://TARGET/PREFIX/system/config"

步骤4: 如果全部返回403

□ 移除 Content-Type header 重试
□ 换 Accept: text/html 或 */* 重试
□ POST 空 body {} 重试 (部分网关POST不拦截空body)
□ 添加 Origin/Referer 为管理后台域名
□ 尝试 GET→POST/PUT/PATCH 方法切换
□ 记录 "垂直越权已测试,N个端点,无发现" 到 findings

确认标准

Token 能访问管理接口 → 垂直越权确认(严重)
  → 立即提取 total/count/size/summary 判断数据量级
  → 对 export 接口→导出文件确认数据泄露量
  → 对响应做敏感字段扫描(password/token/key/secret)
  → 触发 Phase 3.5: 用管理端点发现的数据回溯其他 Phase

---

3. FOUND ≠ CONFIRMED — 三级分类 (MANDATORY)

每个发现必须归类:

CONFIRMED — 已证明实际危害（以下至少满足其一）:
  ✓ 能实际读到不该读的数据 → 具体字段名+数据条数
  ✓ 能实际执行不该执行的操作 → 具体操作+结果
  ✓ 发现的Key能实际利用 → 解密/伪造/登录，至少证明其一
  → 进入报告正文，可标等级（高/中/低）

PENDING — 检测到异常信号但不能证明危害:
  ✗ 发现Key但无法证明利用（"找到硬编码AES密钥"但不知道加密了什么）
  ✗ 路径可访问但每个端点都401/403（Swagger能看文档但全部需要认证）
  ✗ 返回200但data=[]（越权路径存在但无数据返回）
  → 仅入报告附录A（含未确认原因），不入正文和等级

INFO — 发现但无任何可利用路径:
  ✗ 版本号泄露（Server: Apache/2.4.49 — 除非你实际触发了CVE）
  ✗ 无利用链的安全配置缺失（CSP/HSTS单独存在）
  ✗ 静态文件目录列表但只含公开文件
  → 仅入报告附录A（安全加固建议）

确认3问（每个FOUND后必须回答）:
  ① 能实际读到什么不该读的数据?
  ② 能实际执行什么不该执行的操作?
  ③ 发现的Key能实际利用吗?
  → 3问全不能 → PENDING。能回答任一 → CONFIRMED

---

3.1 常见误报模式（以下单项不算漏洞，必须"能利用"才确认）

1. 版本泄露:
   发现 Server: Apache/2.4.49 / 发现 Spring Boot 版本号
   → 不标漏洞。除非你实际触发了CVE或对应版本漏洞
   → 单纯知道版本号 = INFO，入附录A

2. 路径可访问但实际不可用:
   /actuator 返回了paths清单但 /actuator/heapdump 403
   /swagger-ui 可见但每个端点都返回401
   → 不标漏洞。确认标准: 至少有一个端点实际返回了敏感数据

3. 返回空数组/空数据:
   越权接口返回200但data=[] / 水平越权但对方数据不存在
   → 不标漏洞。确认标准: 实际读到了他人数据，不是空壳

4. 安全配置缺失:
   Cookie 无 HttpOnly/Secure / 无 X-Frame-Options / CORS: ACAO:*
   → 不单独标漏洞。必须配合实际攻击场景:
     无HttpOnly → 必须存在XSS才能利用
     无X-Frame-Options → 必须能嵌入iframe并诱导点击
     ACAO:* → 必须实际从恶意域获取到了敏感数据

5. 信息泄露(无法用于进一步攻击):
   错误信息含堆栈但泄露的路径不可用
   备份文件存在但只包含公开信息
   → 确认标准: 泄露的信息能否用于下一步攻击

6. 用自己凭证获取自己数据:
   无session返回"请登录" → 有认证保护
   有session返回自己的手机号/姓名 → 正常业务
   → 必须证明: 用自己的session获取到他人数据，或无session获取到数据

---

4. ⛔ 非漏洞判定规则（优先级最高）

规则1: 用自己的有效凭证获取自己的信息 = 正常业务流程，非漏洞
  例: currentAccount / getUserInfo / exportUserInfo 等接口
  判定标准: 必须证明能获取到他人数据，或无需认证即可获取数据

规则2: 接口响应中包含自己的个人信息 ≠ 信息泄露
  禁止行为: 仅凭"响应中有phone/name/email字段"就标记为信息泄露
  必须证明: 响应中包含他人信息，或信息可被未授权访问

规则3: Token/Session仅用于身份校验且随机生成无法预测/枚举 → 非泄露
  必须证明: token可被预测/枚举 | 可被第三方窃取 | 可越权访问他人数据

规则4: 导出/下载接口仅导出自己的数据 = 正常功能
  必须证明: 可导出他人数据，或未授权可导出

规则5: ⚠️ UI可见性预检 — API返回的数据是否在目标网站页面上已展示?
  例: getAgentList返回uid/userName → 打开目标站/moreAssistant页面
  → 页面已展示创作者名 → 这些字段是公开业务数据 → 跳过标记
  判定: 打开目标站前面对比API响应字段 vs UI展示内容

---

5. Impact 证明标准 (Triage Gate — 6 Check)

每个 finding 必须通过6个检查:

☐ 1. has_target — URL/端点明确
☐ 2. has_vuln_class — 漏洞类型已识别 (IDOR/SQLi/SSRF/...)
☐ 3. has_evidence — 检测证据可复现 (request+response原文)
☐ 4. impact_demonstrated (HARD GATE) — 已证明实际危害
    □ 读到了什么不该读的数据?
      → 具体字段 + 数据条数 + 敏感程度
      → 例: "读取了12,340条用户记录，含手机号和密码哈希"
    □ 执行了什么不该执行的操作?
      → 操作 + 结果 + 权限要求
      → 例: "以普通用户身份删除了管理员账号"
    □ 影响了谁?
      → 自己 / 其他用户 / 所有用户 / 系统
☐ 5. confidence ≥ 0.70 — 置信度达标
☐ 6. data_not_public — API返回的数据未在前端UI公开展示
    → 必须打开目标网站对应前端页面对比确认

未通过 → PENDING_CONFIRMATION (不入正文)
通过 → CONFIRMED → POC Generation → Proof Capture → 中文报告

---

6. 数据联动闭环 (发现后不停止)

确认漏洞后立即执行:

1. 新拿到的数据 → 提取字段名+值 → 回写 data_linkage 值池
2. 新 token/凭据 → 所有端点重测 (尤其是之前 401/403 的)
3. 新发现的内部路径 → GitHub/Gitee 源码泄露搜索
4. 新发现的参数名 → 在所有已知端点测试该参数

示例链:
  IDOR 读到 userId=1 的 email=[e-mail]
  → email 用于登录接口爆破 / 密码重置接口
  → JWT 爆破成功拿到 admin token
  → admin token 打管理接口 → 发现用户导出接口
  → 导出全量用户数据 → 包含更多 userId 和 PII
  → 更多的 userId → 扩大 IDOR 范围

---

7. SRC 合规规则

操作分级

TIER 1 — 允许（常规测试）:
  □ 手工发包（每次≤1个）
  □ 用自己2个测试账号互操作
  □ IDOR: 读≤5条他人数据作为proof
  □ 响应链式挖掘

TIER 2 — 谨慎（需注意）:
  □ 伪造成他人的正常业务请求（如: 用自己的Token+他人的userId）
  □ 密码重置接口测试（仅用自己的邮箱）
  □ 文件上传测试（上传无害标识文本）

TIER 3 — 禁止:
  □ SQLmap / 自动化扫描器
  □ 批量拉取（>5条）
  □ SQL爆表/SSRF扫内网
  □ 删/改真实用户数据
  □ alert()弹窗测XSS → 用<s>XSS</s>+console.log替代

SRC合规声明（报告必须包含）:

本次安全测试声明:
1. 测试仅在授权范围内进行
2. 未对目标系统正常业务造成影响
3. 越权测试数据获取量控制在≤5条作为证明
4. 仅使用自行注册的测试账号进行互操作验证
5. 未使用自动化扫描工具（SQLmap等）
6. 未删除/修改真实用户数据
7. 发现的所有敏感数据在测试完成后已本地销毁

---

8. XSS 预检两步法 (MANDATORY — 禁止使用 alert())

Step 1: 注入 <s>XSS</s>
  → 渲染为删除线 = HTML被解释
  → 显示原文 = 被转义

Step 2 (Step 1通过后): 注入 <img src=x onerror="console.log('xss')">
  → F12 Console 检查日志
  → 出现 'xss' 日志 = XSS确认

原因: alert()阻塞UI，存储型XSS会触发每个访问用户

---

9. 报告生成 (中文 .docx — MANDATORY)

生成前强制步骤

1. 加载 references/report-template.md — 必须已读入上下文
2. 对照 report-template.md 的 "每条漏洞必须包含(8项)" 逐条确认
3. 对照 report-template.md 的 "整份报告必须包含(4项)" 逐条确认
4. curl命令必须自包含真实值: 单行(禁止\续行)、无占位符、无注释
   禁止引用本地文件作为主复现方式
5. 每个curl生成后 → Bash实际执行一次 → 确认200且含预期数据 → 截图
6. 泄露字段清单表必须有（每漏洞一个表格：字段名/含义/敏感等级）
7. gen_report.py必须放 scripts/子目录，禁止放目标根目录
8. 生成后验证: dir output/{target}/reports/*.docx 必须返回至少1个文件

报告结构（对齐京东/讯飞/阿里/补天SRC标准）

封面 — 报告日期 / 漏洞类型 / 自评等级 / 目标站点 / 提交平台
目标系统画像 — IP/Web服务器/WAF/SSL证书/前端框架/已发现API清单/路由表
完整攻击链路图 — ASCII流程图 展示所有漏洞的因果链
一、漏洞信息 — 名称/URL/类型/等级/受影响资产/测试账号 + 漏洞描述
    (名称格式: 越权访问 (IDOR) — 双语标注)
二、漏洞证明 — 复现环境 + 完整HTTP请求/响应原文 + 可复制curl + 截图列表
三、漏洞危害 — 具体泄露数据量(数字,不是"大量") + 受影响用户量级 + 攻击场景
四、修复方案 — P0(立即)/P1(高优)/P2(中优)分级, 每条含具体接口路径
五、漏洞汇总表 — ID/名称/等级/接口/状态 一览表
    只有CONFIRMED入正文，PENDING+INFO仅入附录A
六、SRC合规声明 — 见§7

格式: python-docx生成.docx
输出: output/{target}/reports/
语言: 中文全文（技术术语保留英文，漏洞名称双语标注）

评级速查

IDOR列表端点 (getuserlist, */list, */all等一请求返回全量) → 直接高危/严重
  (但仅返回自己数据=正常业务)
IDOR单资源端点 (?userId=xxx需遍历) → ID可枚举=中危/高危, 不可枚举=低危/中危
  (但仅查到自己的数据=正常业务)
静态文件/模板可访问但内容无敏感数据 → 低危/无 (Quick-Filter)
未授权接口但无法证明可访问实际数据 → 低危 (Impact>Detection不满足)
内部地址/SSO域名泄露无后续利用链 → 低危

→ 完整评级标准见 references/rating-standard.md (阿里SRC 5-level)

---

10. 阶段输出

output/{target}/
├── reports/
│   ├── {finding_id}.docx          # ★ 每个确认漏洞的中文报告
│   ├── summary.docx               # ★ 汇总报告(中文)
│   └── appendix_a.md              # PENDING+INFO项附录
├── findings/
│   ├── _approved.json             # CONFIRMED — 通过Triage的漏洞
│   ├── _pending.json              # PENDING — 待确认的漏洞
│   └── evidence/                  # curl命令 + 截图 + 响应体
├── scripts/
│   └── gen_report.py              # python-docx报告生成脚本
└── poc/
    └── {finding_id}/              # 每个漏洞的PoC脚本（补充附件）