--- name: vibe-pentest description: | 多 Agent 并行架构的 Web 应用渗透测试技能。 流程: 指纹识别 → 后台入口扫描 → 用户提交目标 → 确认测试账号 → 浏览器登录提取凭证 → Katana 爬虫 → 过滤数据 → 攻击面映射 → 多 Agent 并行渗透测试 → 攻击链分析 → 漏洞证据复查 → 导出 JSON 报告 → 主机漏洞扫描 (可选)。 纯黑盒测试，不依赖源码。平台无关设计，可在任意 Agent 平台创建和使用。 metadata: author: helloworld version: "1.0.2" date: 2026-05-20 --- # Vibe Pentest — 多 Agent 并行 Web 渗透测试 ## 目录结构（全部使用相对路径） ```text vibe-pentest/ ├── SKILL.md # 主 skill（整体架构、数据协议、工作流） ├── agents/ │ ├── orchestrator/SKILL.md # 编排 Agent（Phase 0~6 流程控制、任务分发、漏洞复查、攻击链分析、结果聚合） │ ├── injection-agent/ # Agent 1: SQLi/NoSQL/XSS/SSRF/XXE/SSTI/RCE/反序列化/CRLF/XSLT/EL/JNDI/原型污染/走私 │ ├── auth-agent/ # Agent 2: 认证绕过/IDOR/JWT/OAuth/SAML/密码重置/验证码/CSRF/用户枚举 │ ├── file-agent/ # Agent 3: 路径穿越/LFI→RCE/文件上传/文件包含/下载/PHP Wrapper/PEARCMD/Zip Slip │ ├── api-agent/ # Agent 4: API 未授权/BOLA/BFLA/GraphQL/参数篡改/隐藏参数/WebSocket/过度暴露 │ ├── business-agent/ # Agent 5: 业务逻辑/竞争条件(HTTP/1.1+HTTP/2)/支付操纵/价格篡改/CSRF │ └── misc-agent/ # Agent 6: 信息泄露/开放重定向/CORS/CSP/走私/WAF绕过/403绕过/DNS Rebinding/HTTP2 ├── scripts/ │ ├── extract_credentials.py # Phase 2: 浏览器登录 + 凭证提取 │ ├── run_katana.py # Phase 3: Katana 爬虫 │ ├── clean_targets.py # Phase 4: 数据清洗 + 域名过滤 │ ├── admin_scanner.py # Phase 0.5: 后台管理面板扫描 (推荐，无外部依赖) │ ├── admin_scanner.bat # Phase 0.5: 后台管理面板扫描 (Windows 批处理) │ ├── admin_scanner.sh # Phase 0.5: 后台管理面板扫描 (Linux Shell) │ ├── prepare_agent_findings.py # Phase 5: 预生成各 Agent findings 骨架文件 │ ├── generate_report.py # Phase 6: 聚合发现 + JSON 报告 │ ├── verify_findings.py # Phase 5.6: 漏洞证据复查验证 │ ├── run_vuln_scan.py # Phase 7: 主机漏洞扫描包装器 (可选) │ └── vuln_scan.py # Phase 7: 主机/端口漏洞扫描 API 客户端 ├── references/ │ ├── common-paths.md # 377个常见后台/登录路径列表 │ ├── product-fingerprints.md # 100+产品识别正则表达式 │ └── detection-rules.md # 检测规则、验证码检测、误报过滤、置信度评分 └── tools/ ├── katana.exe # Windows amd64 Katana 爬虫本地版本 ├── katana_downloads.json # Katana 多平台下载清单 ├── bin// # run_katana.py 自动下载后的平台专用可执行文件 └── .cache/ # Katana 下载与解压缓存 ``` > **注意**：所有路径均为相对路径，skill 可整体移动到任意位置使用。 > 运行时请在当前目录下创建单独的 `workspace/`（或明确指定的工作目录），所有中间 JSON、最终 `workspace/report.json`、HTML、DOCX 都写入该目录；`vibe-pentest/` 只保留技能与脚本本体，不放运行产物。 ## 架构总览 ```text ┌──────────────────────────────────────────────────────────────────────────────┐ │ Orchestrator Agent │ ├──────────────────────────────────────────────────────────────────────────────┤ │ Phase 0 : 指纹识别 │ │ Phase 0.5 : 后台入口扫描 - 377+ 路径探测 + 80+ 产品指纹识别 │ │ Phase 1 : 授权确认 │ │ Phase 2 : 浏览器登录 + 凭证提取 (scripts/extract_credentials.py) │ │ Phase 3 : Katana 爬虫 (scripts/run_katana.py) │ │ Phase 4 : 数据清洗 (scripts/clean_targets.py) │ │ Phase 4.5 : 攻击面映射 - 根据指纹动态调整 Agent 策略 │ │ Phase 5 : 生成 findings 骨架 (scripts/prepare_agent_findings.py) │ │ : 并行分发 6 个渗透 Agent │ │ Phase 5.5 : 攻击链分析 - 跨 Agent 漏洞组合 │ │ Phase 5.6 : 漏洞证据复查 - 逐一审查 confirmed 漏洞证据 │ │ Phase 6 : 聚合结果 + JSON 报告导出 (scripts/generate_report.py) │ │ Phase 7 : 主机漏洞扫描(可选) (scripts/run_vuln_scan.py，与 Phase 6 并行) │ ├────────────┬────────────┬────────────┬────────────┬────────────┬────────────┤ │ Injection │ Auth │ File │ API │ Business │ Misc │ │ Agent │ Agent │ Agent │ Agent │ Agent │ Agent │ └────────────┴────────────┴────────────┴────────────┴────────────┴────────────┘ ``` ### 需要创建的 Agent（共 7 个） 在任意 Agent 平台上，需要手动创建以下 7 个 agent： | # | Agent 名称 | 类型 | 说明 | 创建文件 | |---|-----------|------|------|---------| | 1 | **orchestrator** | 编排 | 流程控制、任务分发、结果聚合、攻击链分析 | `agents/orchestrator/SKILL.md` | | 2 | **injection-agent** | 渗透 | SQLi/NoSQL/XSS/SSRF/XXE/SSTI/RCE/反序列化/CRLF/XSLT/EL/JNDI/原型污染/PHP类型混淆/HTTP走私 | `agents/injection-agent/SKILL.md` | | 3 | **auth-agent** | 渗透 | 认证绕过/IDOR/暴力破解/会话/JWT/OAuth/SAML/密码重置22模式/验证码20方法/CSRF/用户枚举 | `agents/auth-agent/SKILL.md` | | 4 | **file-agent** | 渗透 | 路径穿越/LFI→RCE(7路径)/文件上传/文件包含/下载/PHP Wrapper矩阵/PEARCMD(4方法)/Zip Slip | `agents/file-agent/SKILL.md` | | 5 | **api-agent** | 渗透 | API未授权/BOLA/BFLA/批量赋值/GraphQL深度/参数篡改/隐藏参数发现/WebSocket安全/过度暴露 | `agents/api-agent/SKILL.md` | | 6 | **business-agent** | 渗透 | 业务流程绕过/竞争条件(HTTP/1.1+HTTP/2单包)/DB隔离级别利用/价格篡改/支付操纵10模式/CSRF | `agents/business-agent/SKILL.md` | | 7 | **misc-agent** | 渗透 | 信息泄露/开放重定向/CORS/CSP/安全头/目录遍历/HTTP走私/WAF绕过/403绕过/DNS Rebinding/HTTP2 | `agents/misc-agent/SKILL.md` | ### 数据交换协议 所有 agent 通过 **共享文件系统** 交换数据，不依赖平台特定的消息传递： **编排 Agent → 渗透 Agent（输入）：** ```text workspace/ ├── fingerprint.json # Phase 0 指纹识别结果 ├── strategy.json # Phase 4.5 攻击面映射策略（含暴力破解决策） ├── targets.txt # 每行一个 URL，渗透 Agent 直接读取 ├── requests.json # 结构化请求列表（含 method、path、params） ├── sessions/ # 凭证目录 │ ├── admin.json # 格式见下方 │ └── user.json └── findings/ # 输出目录（渗透 Agent 写入） ``` **strategy.json 关键字段说明**： ```json { "auth_agent": { "brute_force": { "enabled": false, // true = 执行弱口令爆破, false = 跳过 "reason": "已提供测试账号，跳过暴力破解", // 跳过原因 "max_requests_per_endpoint": null, // 每个登录接口最大请求数（仅 enabled=true 时有效） "top100_limit": null, // top100 字典取前 N 条（仅 enabled=true 时有效） "common_usernames": null // 用户名列表 }, "derived_credentials": [ // 根据指纹动态衍生的产品凭据 { "product": "sangfor", "default_pairs": [{"username": "admin", "password": "sinfor"}], "derived_usernames": ["sangfor", "admin", "root"], "derived_passwords": ["sangfor", "Sangfor", "sangfor2025", "s@ngf0r@123", ...] } ] } } ``` **暴力破解决策逻辑（由编排 Agent 在 Phase 4.5 执行）：** ```text 用户提供了测试账号? ├─ 是 → enabled = false (已提供账号，无需爆破) └─ 否 → 登录页有验证码? ├─ 是 → enabled = false (有验证码，无法自动爆破) └─ 否 → enabled = true (无账号且无验证码，执行弱口令爆破) 无论 enabled 状态，均执行以下轻量检查： 1. 产品默认凭据（来自 derived_credentials） 2. 固定 top100 字典前 5 条 ``` 说明： - 骨架文件中的示例值仅用于提示字段结构，属于待回填占位内容；渗透 Agent 必须按真实检测结果覆写这些值 - `findings` 可以为空数组；如发现多个漏洞，必须在 `findings` 中追加多个对象，而不是只保留一条 - `vuln_id` 按各 Agent 前缀递增编号，例如 `INJ-001`、`INJ-002`、`AUTH-001`、`FILE-001` **编排 Agent → 攻击链分析（输出）：** ```json { "chains": [ { "chain_id": "CHAIN-001", "title": "LFI + PHP Wrapper → RCE", "severity": "critical", "steps": [ {"step": 1, "finding_from": "file-agent", "vuln_id": "FILE-001", "description": "发现 LFI 漏洞"}, {"step": 2, "finding_from": "file-agent", "vuln_id": "FILE-002", "description": "通过 php://filter chain 实现 RCE"} ], "impact": "攻击者可从 LFI 升级为远程代码执行" } ] } ``` **sessions/{username}.json 格式（凭证提取脚本输出）：** ```json { "target": "...", "capture_time": "...", "roles": [ { "role_label": "admin", "cookies": [{"name": "...", "value": "...", "secure": true, "httpOnly": true}], "auth_cookie_string": "key1=val1; key2=val2", "tokens": [{"type": "localStorage", "key": "token", "value": "eyJ..."}], "jwt_analysis": [{"payload": {"sub": "...", "role": "admin"}, "expires_at": "..."}], "auth_headers": [{"name": "Authorization", "value": "Bearer eyJ..."}], "storage": {"localStorage": {}, "sessionStorage": {}} } ] } ``` **report_{timestamp}.json 格式（Phase 6 最终输出）：** ```json { "report_meta": { "report_id": "VUL-2026-XXXXX", // 唯一报告 ID，格式 VUL-年份-5位随机大写字母数字 "generated_at": "2026-05-15T02:00:00Z", // ISO 8601 UTC 时间 "tester": "vibe-pentest-agent-v1", // 固定值 "scope": { "target_url": "http://target:port/", // 测试目标 URL "tech_stack": ["java", "spring_boot_3", "halo_cms"] // 指纹识别结果 }, "test_accounts": [ // 测试账号列表 {"role": "管理员", "username": "admin", "password": "***"} ] }, "summary": { "total": 7, // 漏洞总数，必须等于下面各 severity 数量之和 "critical": 0, // 严重 "high": 1, // 高危 "medium": 1, // 中危 "low": 4, // 低危 "info": 1 // 信息 }, "vulnerabilities": [ { "vuln_id": "VUL-001", // 按 severity→confidence 排序后从 VUL-001 递增（严重优先） "title": "漏洞标题 - 简述路径和问题", "type": "information_disclosure", // 英文类型，见下方 type 枚举表 "type_zh": "信息泄露", // 中文类型，同一 type 始终使用同一表述 "severity": "high", // 枚举: critical, high, medium, low, info "confidence": "confirmed", // 枚举: confirmed, likely, potential "authenticated": true, // boolean，是否需要认证才能触发 "target_url": "http://...", // 漏洞目标 URL "description": "详细描述，包含影响分析。", "RepairSuggestions": "1. 针对该漏洞的具体修复建议；2. 多条建议用分号分隔。", "http_interactions": [ { "seq": 1, "label": "此交互的说明", "request": {"method": "GET", "url": "http://...", "headers": {}, "body": null}, "response": {"status_code": 200, "headers": {}, "body": "..."} } ] } ] } ``` **report_{timestamp}.json 格式约束：** | 字段 | 类型 | 约束 | |------|------|------| | `vuln_id` | string | `VUL-NNN` 格式，NNN 从 001 起，按 severity→confidence 排序分配（严重优先） | | `type` | string | 见下方 type 枚举表，不在表中的值将被映射为 `unknown` | | `type_zh` | string | 由 type 自动映射，同一 type 始终使用相同中文表述 | | `severity` | string | `critical` > `high` > `medium` > `low` > `info` | | `confidence` | string | `confirmed`（有完整 HTTP 证据）、`likely`（间接证据）、`potential`（疑似） | | `authenticated` | boolean | `true` = 需要登录，`false` = 匿名可触发 | | `http_interactions` | array | 至少 1 条，每条必须包含 request.method、request.url、response.status_code | **type → type_zh 映射表（部分常用）：** | type | type_zh | type | type_zh | |------|---------|------|---------| | `sqli` / `nosqli` | SQL注入 | `xss_stored` / `xss_reflected` / `xss_dom` | XSS注入 | | `ssrf` | SSRF | `xxe` | XXE注入 | | `ssti` | 模板注入 | `rce` | 远程代码执行 | | `lfi` / `rfi` | 文件包含 | `dir_traversal` | 目录穿越 | | `idor` | 越权访问 | `broken_access_control` | 访问控制缺陷 | | `auth_bypass` | 认证绕过 | `csrf` | CSRF | | `information_disclosure` | 信息泄露 | `open_redirect` | 开放重定向 | | `insecure_deserialization` | 反序列化漏洞 | `prototype_pollution` | 原型污染 | | `command_injection` | 命令注入 | `request_smuggling` | HTTP走私 | | `file_upload` | 文件上传漏洞 | `webshell` | Webshell | | `weak_password` | 弱口令 | `brute_force` | 暴力破解 | | `workflow_bypass` / `pricing_manipulation` / `coupon_abuse` / `subscription_hijack` | 业务逻辑漏洞 | `race_condition` | 竞争条件 | | `waf_bypass` | WAF绕过 | `clickjacking` | 点击劫持 | | `cookie_security` | Cookie安全问题 | `unknown` | 未分类 | ## 工作流程 ### Phase 0~4：编排 Agent 执行 编排 Agent 按顺序执行以下阶段： 0. **指纹识别** — 自动检测 Web 服务器、后端框架、数据库类型、WAF 厂商，输出 `workspace/fingerprint.json` 0.5. **后台入口扫描** — 调用 `scripts/admin_scanner.py`，对 377+ 个常见管理路径进行探测，识别 80+ 产品（Nacos/Druid/Jenkins/用友/金蝶/致远/深信服等），输出结果合并到 `workspace/fingerprint.json` 的 `login_pages` 和 `admin_panels` 字段，发现的 URL 追加到后续 `workspace/targets.txt` 1. **授权确认** — 向用户确认目标 URL、测试账号、授权范围（展示 Phase 0.5 发现的管理后台列表） 2. **浏览器登录** — 调用 `scripts/extract_credentials.py`，为每个测试账号启动浏览器登录并提取凭证 3. **Katana 爬虫** - 须在沙箱环境外运行爬虫工具：调用 `{SKILL_ROOT}/scripts/run_katana.py`，匿名 + 认证模式爬取目标；脚本默认使用适配 Windows 平台爬虫工具 `{SKILL_ROOT}/tools/katana.exe`，缺失时按 `tools/katana_downloads.json` 自动下载当前平台适配版本 - `Katana` 爬虫关键点： - `Katana` 运行结束、超时或被停止后，不得只依据 `crawl_summary.json` 判断爬取结果，必须优先检查实际输出文件：`workspace/` 下的结果 - 如果 `Katana` 超时或被停止，必须等待 5 秒后再次检查输出文件，避免进程退出后文件延迟落盘 - 爬取目标应严格使用用户提供的完整 URL，禁止将目标自动转换为根目录地址（如 `/`）、删除路径层级或仅保留域名，所有操作必须基于用户指定路径进行。 4. **数据清洗** — 调用 `scripts/clean_targets.py`，过滤外部域名和静态资源，输出 `workspace/targets.txt` ### Phase 4.5：攻击面映射 根据 Phase 0 指纹结果和 Phase 0.5 后台入口扫描结果，为各 Agent 生成针对性检测策略（`workspace/strategy.json`）： - 识别到 Nacos → Nacos 默认凭证、未授权访问检测 - 识别到 Druid → Druid 未授权访问、SQL 监控泄露 - 识别到 Jenkins → Jenkins Script Console RCE、未授权访问 - Java 后端 → Ghost Bits Cast、JNDI、SpEL、Spring 路径遍历、AJP Ghostcat - PHP 后端 → PHP Wrapper 矩阵、PEARCMD、disable_functions bypass、php://filter chain - Node.js → 原型污染、express.static 双解码 - Python → Flask PIN 计算、Jinja2 SSTI - Cloudflare WAF → Cloudflare 特定绕过技术 ### Phase 5：多 Agent 并行渗透测试 编排 Agent 通过平台的工作流能力（如 Coze 的并行节点、Dify 的分支）同时启动 6 个渗透 Agent： - 编排 Agent 先调用 `prepare_agent_findings.py`，预生成 6 个标准化骨架文件 - 脚本命令示例：`python {SKILL_ROOT}/scripts/prepare_agent_findings.py`，不需要加参数，会自动生成 6 个标准化骨架文件到 `workspace/findings/{agent_name}.json`，后续子 Agent 回填相应文件即可 - 每个渗透 Agent 读取 `workspace/targets.txt` 获取测试目标 - 各 Agent 读取 `workspace/strategy.json` 调整检测重点 - 每个渗透 Agent 读取并仅回填自己的骨架文件 `workspace/findings/{agent_name}.json`，不得覆盖其他 Agent 的输出；骨架中的占位值必须覆写，发现多个漏洞时需继续向 `findings` 追加对象 - 每个 Agent 必须先建立本职责范围内的一级攻击面清单，再递归展开二级/三级功能点 - 每个 Agent 必须从 HTML 表单、链接、按钮、隐藏字段、JS 请求、API 响应中继续提取子功能和隐藏入口 - 每个 Agent 必须对可疑点执行主动深入探测：基线请求、变体请求、对照请求、权限对比、参数边界、编码变体、方法变体 - 每个 Agent 必须根据业务需要执行认证态/未认证态对比：匿名、已登录、去认证重放、低权限重放、高权限对照（如有） - 每个 Agent 不得把第一个发现或第一个漏洞当作终点，必须继续覆盖同类功能、相邻接口、同参数不同方法和认证态差异 - 每个 Agent 只测试自身职责范围内的漏洞类型 - 每个 Agent 完成全部回填后，根据用户需求翻译 `workspace/findings/{agent_name}.json` 文件（默认翻译成中文，只需翻译标题、漏洞描述等说明性文字，不修改其它字段） - 编排 Agent 等待所有 6 个 Agent 完成 ### Phase 5.5：攻击链分析 编排 Agent 跨 Agent 发现关联，构建攻击链： - LFI + 文件上传 → RCE 链 - SSRF + Redis/FastCGI → RCE 链 - XSS + CSRF → 数据窃取链 - IDOR + Mass Assignment → 提权链 - 输出 `workspace/attack_chains.json` ### Phase 5.6：漏洞证据复查 ⚠️ **强制规则：每个 confirmed 漏洞必须通过证据复查才能进入最终报告。** 编排 Agent 必须： 1. **运行自动扫描**：`python scripts/verify_findings.py ` - 检查响应状态码（404/500 等异常） - 检查类型专属证据特征（SQLi 必须有 SQL 报错，XSS 必须有未转义 payload 等） - 检查响应体质量（空响应体、错误页面特征） - 输出 `verification.json`（verified / needs_review / reject） 2. **逐一人工审查 needs_review 的漏洞**： - 读取 finding 的完整 `http_interactions` - 按类型专属标准判断请求和响应是否真正证明了漏洞 - 三种决定：保持 confirmed → 降级为 likely → 剔除 3. **输出 `workspace/review_report.json`** 记录每个决策及原因 4. **写回 findings 文件**：降级的修改 confidence，剔除的删除条目 ### Phase 6：生成最终报告（编排 Agent 执行） #### 步骤 1：使用 Python 脚本汇总 findings目录下所有 JSON 文件 当 Phase 5.6 漏洞证据复查结束后，必须使用 `scripts/generate_report.py` 汇总 `workspace/findings/*.json`生成`workspace/report_{timezone.utc}.json`(工作目录内的最终 JSON 报告)。 - 基本命令格式：python scripts/generate_report.py --target-url <目标URL> [可选参数] - 必需参数： - workspace：vibe-pentest 工作目录路径，脚本会在其中找 findings/ 子目录 - --target-url：渗透测试的目标 URL - 可选参数： - --tech-stack：识别到的技术栈列表，使用示例：--tech-stack Java Spring Boot MySQL，该值可参考`workspace/fingerprint.json`内容的`tech_stack`字段 - --test-accounts：测试账户 JSON 数组，默认值为 []，当用户提供了测试账户时才需要使用此参数 - --report-id：自定义报告 ID ，使用示例：--report-id VUL-2026-XXXXX，默认使用5个随机字符串 - 示例： ```bash python scripts/generate_report.py workspace --target-url https://example.com python scripts/generate_report.py workspace --target-url https://example.com --tech-stack Java Spring Nginx MySQL python scripts/generate_report.py workspace --target-url https://example.com --report-id VUL-2026-ABCDE ``` #### 步骤 2：翻译说明性内容 根据用户需求检查并翻译 `workspace/report_{timezone.utc}.json` 中的说明性文本字段：`RepairSuggestions`、`title`、`description`、`http_interactions[].label`。若这些字段为英文或中英混杂，则额外执行一次说明性文本翻译，默认翻译为中文；但不得翻译路径、参数名、字段名、payload、状态码、URL 中的技术片段。 #### 步骤 3：使用 Python 脚本生成最终 HTML 和 Word 报告 基于步骤 1 生成的 `workspace/report_{timezone.utc}.json`，编排 Agent 调用对应的 Python 脚本，生成对应的报告。 示例： ```bash python report_renderers/generate_html.py workspace/report_{timezone.utc}.json workspace/security-assessment-report.html python report_renderers/generate_report.py workspace/report_{timezone.utc}.json workspace/security-assessment-report.docx ``` 不要使用额外封装层，不要修改 `report.json` 结构，也不要把输出写回 `vibe-pentest/` 目录。 ### Phase 7：主机漏洞扫描（可选，与 Phase 6 并行，用户没有要求可跳过执行） ⚠️ **Phase 7 与 Phase 6 并行执行，互不依赖。Phase 7 是可选的，用户没有要求主机漏洞扫描则跳过。** **前置条件**：`session.json` 中包含 `scanner` 字段，或用户通过命令行提供 scanner 参数。 **执行**：调用 `scripts/run_vuln_scan.py` 包装脚本： ```bash python scripts/run_vuln_scan.py --workspace ``` 脚本自动完成： 1. 从 `session.json` 中的 `target_url` 解析 host 和 port 2. 从 `session.json` 中的 `scanner` 获取漏扫系统 API 地址和 access_token 3. 调用 `vuln_scan.py` 创建扫描任务 → 等待完成 → 生成报表 → 下载 zip 4. 将下载的 zip 复制到 `workspace/vuln_scan_report.zip` **Phase 1 集成**：在授权确认阶段询问用户是否启用主机漏洞扫描： - 如果启用，询问漏扫系统 API 地址和 access_token - 将 scanner 配置写入 `session.json` - 如果不启用，跳过 Phase 7 ## 各 Agent 职责 | Agent | 负责漏洞类型 | type 枚举值 | |-------|-------------|------------| | **injection-agent** | SQL注入、NoSQL注入、XSS(存储/反射/DOM)、SSRF、XXE、SSTI、命令注入、反序列化、CRLF、XSLT、EL、JNDI、原型污染、PHP类型混淆、HTTP走私 | `sqli`, `nosqli`, `xss_stored`, `xss_reflected`, `xss_dom`, `ssrf`, `xxe`, `ssti`, `rce`, `insecure_deserialization`, `crlf_injection`, `xslt_injection`, `el_injection`, `jndi_injection`, `prototype_pollution`, `type_juggling`, `request_smuggling` | | **auth-agent** | 认证绕过、IDOR、暴力破解、会话管理、JWT/OAuth/SAML/OIDC、密码重置绕过(22模式)、验证码绕过(20方法)、CSRF、不安全随机数、用户枚举 | `auth_bypass`, `idor`, `broken_access_control`, `csrf`, `information_disclosure` | | **file-agent** | 路径穿越、LFI→RCE(7路径)、文件上传、文件包含、文件下载、PHP Wrapper矩阵、PEARCMD(4方法)、Zip Slip、SVG/CSV注入 | `lfi`, `rce`, `xss_stored`, `information_disclosure`, `unknown` | | **api-agent** | API未授权、BOLA、BFLA、批量赋值、GraphQL深度测试、参数篡改、隐藏参数发现、WebSocket安全、过度数据暴露 | `broken_access_control`, `idor`, `sqli`, `unknown`, `information_disclosure` | | **business-agent** | 业务流程绕过、竞争条件(HTTP/1.1+HTTP/2单包)、DB隔离级别利用、价格篡改、优惠券滥用、数量操纵、订阅劫持、支付操纵(10模式)、状态机绕过、CSRF高级绕过 | `workflow_bypass`, `race_condition`, `pricing_manipulation`, `coupon_abuse`, `unknown`, `subscription_hijack`, `csrf` | | **misc-agent** | 信息泄露、开放重定向、CORS/CSP、安全头缺失、目录遍历、HTTP走私(TE.TE8变体)、WAF绕过(厂商矩阵)、401/403绕过(11类路径)、DNS Rebinding、HTTP2攻击、子域名接管、Web缓存欺骗、Clickjacking、悬空标记注入、Host头攻击 | `information_disclosure`, `open_redirect`, `broken_access_control`, `request_smuggling`, `waf_bypass`, `ssrf`, `clickjacking`, `xss_reflected` | ## 安全规则 1. **严格限制目标域名**，不测试范围外的任何地址 2. **不执行破坏性操作**：不删除数据、不修改业务数据、不发起 DoS 3. **凭证安全**：如果 `sessions/*.json` 包含敏感信息，测试完成后提醒用户删除 4. **速率控制**：请求间保持合理间隔，避免触发 WAF 或对服务造成影响 ## 反幻觉规则 1. 只报告实际发送过请求并收到响应的漏洞 2. 每个漏洞必须有完整的 HTTP 交互证据（request + response） 3. 不猜测不存在的路径或接口，所有测试目标必须来自爬取结果 4. 置信度标记：`confirmed`（有证据）、`likely`（间接证据）、`potential`（疑似） 5. 没有证据时不创建漏洞条目 6. 发现漏洞不等于完成测试；必须继续覆盖同类功能、相邻接口、同参数不同方法和认证态差异 7. 认证态对比不足、缺少对照请求或缺少真实 HTTP 证据时，不得标记为 `confirmed`