name: vibe-pentest description: | AI 渗透测试:多 Agent 并行架构的 Web 应用渗透测试技能。 流程: 指纹识别 → 后台入口扫描 → API 预扫描 → 浏览器登录提取凭证(可选) → GoSpider 爬虫 → 过滤数据 → 指纹汇总 → 多 Agent 并行渗透测试 → 攻击链分析 → 漏洞证据复查 → 导出 JSON 报告 → 主机漏洞扫描 (可选)。 纯黑盒测试,不依赖源码。平台无关设计,可在任意 Agent 平台创建和使用。 metadata: author: helloworld version: "1.0.17" date: 2026-06-23
Vibe Pentest — 多 Agent 并行 Web 渗透测试
启动前快速 Git 自更新
每次调用本 skill 时,在开始正式任务前优先执行:
python {SKILL_ROOT}/scripts/auto_update_skill.py {SKILL_ROOT} --json
该脚本负责快速检查并同步当前 skill 项目;如果更新失败、超时、无网络、无法获取远端状态,或 SKILL_ROOT 目录不是 Git 仓库,直接跳过更新并继续执行用户任务,不要卡住。
如果 git pull 有文件冲突,脚本会自动将远端最新文件覆盖到本地冲突文件,但不会执行 git reset --hard 之类的全局破坏性操作。
如果自动更新结果的 reason 为 updated 或 updated_with_conflict_resolution,必须先重新读取主 SKILL.md,再继续后续步骤。
启动前运行子 Agent 创建脚本
开始渗透前,在当前项目目录下,直接调用脚本创建Agent python {SKILL_ROOT}/scripts/install_sub_agents.py --provider {provider} --force 提前创建实际启用的子 Agent。
--provider 应根据当前智能体平台选择,例如 qoder、opencode、trae、claude、workbuddy、codebuddy,也支持自定义名称。
命令示例:
python {SKILL_ROOT}/scripts/install_sub_agents.py --provider qoder --force
启动前创建 workspace 目录
开始新任务前,必须先检查当前项目目录下是否已存在 workspace/ 目录。
如果已存在 workspace/,先将其重命名为 workspace_{YYYYMMDD_HHmmss},其中 YYYYMMDD_HHmmss 为当前时间戳,例如 workspace_20260605_143025,用于保留旧任务数据。命令示例:
- Windows (PowerShell):
Rename-Item -Path "workspace" -NewName "workspace_20260605_143025" - Linux/macOS (Bash):
mv workspace workspace_20260605_143025请根据当前操作系统选择正确的命令,若无法重命名,不得删除旧目录。
旧目录重命名完成后,再创建新的空 workspace/ 目录,确保本次新任务的中间文件、扫描结果和最终报告都写入新创建的 workspace/ 目录。
SKILL 目录结构(全部使用相对路径)
vibe-pentest/
├── SKILL.md # 主 skill(整体架构、数据协议、工作流)
├── agents/
│ ├── injection-agent/ # Agent 1: 注入类漏洞正式执行规范
│ ├── auth-agent/ # Agent 2: 认证、会话、令牌与协议流正式执行规范
│ ├── file-agent/ # Agent 3: 文件系统访问、解析链与 RCE 升级正式执行规范
│ ├── api-agent/ # Agent 4: API 资源授权、对象归属与接口扩散正式执行规范
│ ├── business-agent/ # Agent 5: 业务状态机、竞争条件与真实业务影响正式执行规范
│ ├── misc-agent/ # Agent 6: 外围攻击面、协议边界与配置风险正式执行规范
│ ├── poc-agent/ # Agent 7: 基于指纹的已知漏洞 POC 验证正式执行规范
│ └── vuln-analysis-agent/ # Agent 8: 攻击链分析与漏洞证据复查正式执行规范
├── scripts/
│ ├── run_fingerprint.py # Phase 0: Web 指纹识别
│ ├── fingerprints_rules/ # Phase 0: 指纹规则库(run_fingerprint.py 依赖)
│ ├── poc/ # Phase 5 POC Agent: Nuclei YAML 格式 POC 文件
│ ├── admin_scanner.py # Phase 0.5: 后台管理面板扫描
│ ├── admin_scanner.bat # Windows 启动包装
│ ├── admin_scanner.sh # Linux 启动包装
│ ├── extract_credentials.py # Phase 2: 浏览器登录 + 凭证提取
│ ├── run_gospider.py # Phase 3: GoSpider 爬虫
│ ├── clean_targets.py # Phase 4: 数据清洗 + 域名过滤
│ ├── api_discovery.py # API 预扫描 1: 接口发现
│ ├── sensitive_extract.py # API 预扫描 2: 敏感参数提取
│ ├── deduplicate.py # API 预扫描 3: 去重与聚合
│ ├── prepare_agent_findings.py # Phase 5: 预生成 findings 骨架
│ ├── verify_findings.py # Phase 5.6: 漏洞证据复查
│ ├── generate_report.py # Phase 6: 生成 JSON 报告
│ ├── install_sub_agents.py # 安装 8 个子 Agent 定义到平台目录
│ ├── auto_update_skill.py # 启动前快速 Git 自更新
│ ├── run_vuln_scan.py # Phase 7: 主机漏洞扫描包装器(可选)
│ ├── vuln_scan.py # Phase 7: 主机/端口漏洞扫描客户端
│ ├── http_test.py # ★ 统一 HTTP 发包工具
│ ├── dnslog.py # ★ DNS 回调 OOB 验证工具
│ └── deserialization_payload.py # Java 反序列化 payload 生成工具
├── references/
│ ├── sub_agents/ # 8 个子 Agent 的可直接复制创建定义
│ ├── pentest_skills/ # 各漏洞专项测试 Skill 与 INDEX 路由
│ ├── common-paths.md # 常见后台/登录路径列表
│ ├── report-json-format.md # 最终报告 JSON 格式约束
│ ├── dnslog-usage.md # dnslog.py 用法参考
│ └── http-test-usage.md # http_test.py 用法参考
├── report_renderers/
│ ├── generate_word.py # Word 报告渲染器
│ └── generate_html.py # HTML 报告渲染器
└── tools/
├── gospider_downloads.json # GoSpider 多平台下载清单
├── gospider(.exe) # GoSpider 可执行文件
└── .cache/ # GoSpider 下载与解压缓存
注意:所有路径均为相对路径,skill 可整体移动到任意位置使用。
架构总览
┌──────────────────────────────────────────────────────────────────────────────┐
│ Main Skill Flow │
├──────────────────────────────────────────────────────────────────────────────┤
│ Phase 0 : 指纹识别 │
│ Phase 0.5 : 后台入口扫描 - 377+ 路径探测 + 80+ 产品指纹识别 │
│ Phase 1 : 授权确认 │
│ Phase 2 : 浏览器登录 + 凭证提取 (scripts/extract_credentials.py) │
│ Phase 3 : GoSpider 爬虫 (scripts/run_gospider.py) │
│ Phase 4 : 数据清洗 (scripts/clean_targets.py) │
│ Phase 4.5 : 指纹汇总(汇总 fingerprint/admin_scan/api_discovery 到 tech_stack)│
│ Phase 5 : 生成 findings 骨架 (scripts/prepare_agent_findings.py) │
│ : 并行分发启用的渗透 Agent(按提示词指定) │
│ Phase 5.5 : 调用漏洞综合分析 Agent - 跨 Agent 漏洞组合 │
│ Phase 5.6 : 复用漏洞综合分析 Agent - 逐一审查 confirmed 漏洞证据 │
│ Phase 6 : 聚合结果 + JSON 报告导出 (scripts/generate_report.py) │
│ Phase 7 : 主机漏洞扫描(可选) (scripts/run_vuln_scan.py,与 Phase 6 并行) │
├────────────┬────────────┬────────────┬────────────┬────────────┬────────────┬────────────┤
│ Injection │ Auth │ File │ API │ Business │ Misc │ POC │
│ Agent │ Agent │ Agent │ Agent │ Agent │ Agent │ Agent │
└────────────┴────────────┴────────────┴────────────┴────────────┴────────────┴────────────┘
需要创建的渗透 agent(按提示词指定启用)
| # | Agent 名称 | 类型 | 职责范围 | 创建 Agent 定义文件 |
|---|---|---|---|---|
| 1 | injection-agent | 渗透 | 负责所有注入类漏洞检测:SQLi/NoSQL/XSS(存储/反射/DOM)/SSRF/XXE/SSTI/RCE/反序列化/CRLF/XSLT/EL/JNDI | references/sub_agents/injection-agent.md |
| 2 | auth-agent | 渗透 | 负责认证与会话类漏洞检测:认证绕过/暴力破解/会话管理/JWT/OAuth/SAML/密码重置绕过/验证码绕过/不安全随机数/用户枚举/OIDC/CSRF。暴力破解为条件执行:根据测试账号和验证码情况自主决策。 | references/sub_agents/auth-agent.md |
| 3 | file-agent | 渗透 | 负责文件类漏洞检测:路径穿越/LFI/RFI/LFI→RCE、任意文件上传、文件包含、任意文件下载、Zip Slip、SVG/CSV 注入、PHP Wrapper 利用、PEARCMD RCE、编辑器路径利用、敏感文件泄露与文件解析链风险。 | references/sub_agents/file-agent.md |
| 4 | api-agent | 渗透 | 负责 API 安全类漏洞检测:未授权访问/BOLA/BFLA/批量赋值/GraphQL 深度测试/API 参数篡改/隐藏参数发现/WebSocket 安全/API 版本枚举/过度数据暴露 | references/sub_agents/api-agent.md |
| 5 | business-agent | 渗透 | 负责业务逻辑漏洞检测:业务流程绕过、状态机缺陷、竞态滥用、价格篡改、优惠券滥用、库存与数量操纵,以及订单、支付、订阅等场景中的业务规则滥用 | references/sub_agents/business-agent.md |
| 6 | misc-agent | 渗透 | 负责外围攻击面与协议边界安全检测:信息泄露/开放重定向/CORS/CSP/安全头/目录遍历/子域名接管/401-403绕过/Web缓存欺骗/Clickjacking/Host头攻击 | references/sub_agents/misc-agent.md |
| 7 | poc-agent | POC验证 | 基于指纹识别结果,匹配 POC YAML 文件并通过 http_test.py 验证已知漏洞。指纹识别 → POC 匹配 → 发包验证 → 输出确认漏洞 | references/sub_agents/poc-agent.md |
需要创建的 漏洞综合分析 agent
| # | Agent 名称 | 类型 | 职责范围 | 创建 Agent 定义文件 |
|---|---|---|---|---|
| 1 | vuln-analysis-agent | 综合分析 | Vibe Pentest 漏洞综合分析 Agent。固定负责 Phase 5.5 攻击链分析与 Phase 5.6 使用 verify_findings.py 脚本检查 | references/sub_agents/vuln-analysis-agent.md |
数据交换协议
所有 agent 通过 共享文件系统 交换数据,不依赖平台特定的消息传递:
主流程 → 渗透 Agent(输入):
workspace/
├── fingerprint.json # Phase 0 指纹识别结果
├── targets.txt # 极简目标清单:先 base_url,再缩进列出该站点 URL
├── sessions/ # 凭证目录
│ ├── admin.json # 格式见下方
│ └── user.json
└── findings/ # 输出目录(渗透 Agent 写入)
主流程 → 漏洞综合分析 Agent(输入):
workspace/
├── findings/ # 已启用的渗透 Agent 已回填完成的 findings 文件
├── fingerprint.json # 指纹识别结果
├── targets.txt # 极简分组目标清单
└── sessions/ # 凭证目录(需要判断认证边界时读取)
说明:
- 骨架文件中的示例值仅用于提示字段结构,属于待回填占位内容;渗透 Agent 必须按真实检测结果覆写这些值
findings可以为空数组;如发现多个漏洞,必须在findings中追加多个对象,而不是只保留一条vuln_id按各 Agent 前缀递增编号,例如INJ-001、INJ-002、AUTH-001、FILE-001
sessions/{username}.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 最终输出):
{
"report_meta": {
"report_id": "VUL-2026-XXXXX", // 唯一报告 ID,格式 VUL-年份-5位随机大写字母数字
"generated_at": "2026-05-15 02:00:00", // 报告生成时间
"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_test_commands": [ // 可选,漏洞验证回放命令
{
"label": "漏洞验证回放命令",
"command": "python \"d:/vibe_pentest/scripts/http_test.py\" --url \"http://...\" --method GET --show-command --show-summary --include-headers",
"expected_evidence": "执行后应看到的关键响应证据"
}
],
"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 枚举表(共 42 种),不在表中的值将被映射为 unknown |
type_zh |
string | 由 type 自动映射,同一 type 始终使用相同中文表述 |
severity |
string | critical > high > medium > low > info |
confidence |
string | confirmed(有完整 HTTP 证据)、likely(间接证据)、potential(疑似) |
authenticated |
boolean | true = 需要登录,false = 匿名可触发 |
http_test_commands |
array | 可选;用于保留可直接复制回放的 http_test.py 命令,建议包含 label、command、expected_evidence |
http_interactions |
array | 至少 1 条,每条必须包含 request.method、request.url、response.status_code |
type -> type_zh 漏洞类型映射表:
| type | type_zh | type | type_zh |
|---|---|---|---|
sqli |
SQL注入 | nosqli |
SQL注入 |
xss_stored |
XSS注入 | xss_reflected |
XSS注入 |
xss_dom |
XSS注入 | ssrf |
SSRF |
xxe |
XXE注入 | ssti |
模板注入 |
rce |
远程代码执行 | command_injection |
命令注入 |
insecure_deserialization |
反序列化漏洞 | crlf_injection |
CRLF注入 |
xslt_injection |
注入攻击 | el_injection |
注入攻击 |
jndi_injection |
注入攻击 | prototype_pollution |
原型污染 |
type_juggling |
类型混淆 | request_smuggling |
HTTP走私 |
auth_bypass |
认证绕过 | idor |
越权访问 |
broken_access_control |
访问控制缺陷 | csrf |
CSRF |
weak_password |
弱口令 | brute_force |
暴力破解 |
lfi |
文件包含 | rfi |
文件包含 |
dir_traversal |
目录穿越 | file_upload |
文件上传漏洞 |
webshell |
Webshell | ||
information_disclosure |
信息泄露 | open_redirect |
开放重定向 |
url_redirect |
开放重定向 | cookie_security |
Cookie安全问题 |
git_exposure |
信息泄露 | directory_listing |
信息泄露 |
waf_bypass |
WAF绕过 | clickjacking |
点击劫持 |
workflow_bypass |
业务逻辑漏洞 | race_condition |
竞争条件 |
pricing_manipulation |
业务逻辑漏洞 | coupon_abuse |
业务逻辑漏洞 |
subscription_hijack |
业务逻辑漏洞 | ||
unknown |
未分类 |
工作流程
Phase 0~4:主流程执行
主流程按顺序执行以下阶段:
- 指纹识别
- 调用
{SKILL_ROOT}/scripts/run_fingerprint.py - 单站点目标使用
-u {base_url1} --json -o workspace/fingerprint.json,多站点目标使用-u {base_url1} -u {base_url2} --json -o workspace/fingerprint.json - 固定输出:
workspace/fingerprint.json - 该工具基于 DSL 表达式匹配,支持 favicon mmh3 hash、关键词匹配、正则匹配,指纹库位于
{SKILL_ROOT}/scripts/fingerprints_rules/ - 命令示例:
python {SKILL_ROOT}/scripts/run_fingerprint.py -u {base_url} --json -o workspace/fingerprint.json
0.5. 后台入口扫描
- 调用
{SKILL_ROOT}/scripts/admin_scanner.py - 单站点目标使用
--target {base_url1},多站点目标使用--target {base_url1} --target {base_url2} - 固定输出:
workspace/admin_scan_summary.json - 状态检查:该检查非常关键;脚本运行结束后,仍然要检查状态文件
workspace/admin_scan_status.json,并且只有status = completed才能进入下一步;轮询查看间隔建议10秒一次或更长,期间不得重复执行脚本;可以通过检查脚本进程是否存在进行辅助判断,若进程存在,则说明后台任务仍在执行中,需要耐心等待状态变成completed - 命令示例:
python {SKILL_ROOT}/scripts/admin_scanner.py --target {base_url}
- API 预扫描
- 调用
{SKILL_ROOT}/scripts/run_api_prescan.py - 单站点目标使用
--target {base_url1},多站点目标使用--target {base_url1} --target {base_url2} - 固定输出:
workspace/api_discovery_summary.json、workspace/sensitive_findings_summary.json。 - 状态检查:该检查非常关键;脚本运行结束后,仍然要检查状态文件
workspace/api_prescan_status.json,并且只有status = completed才能进入下一步;轮询查看间隔建议10秒一次或更长,期间不得重复执行脚本;可以通过检查脚本进程是否存在进行辅助判断,若进程存在,则说明后台任务仍在执行中,需要耐心等待状态变成completed - 命令示例:
python {SKILL_ROOT}/scripts/run_api_prescan.py --target {base_url}
- 浏览器登录 — 调用
{SKILL_ROOT}/scripts/extract_credentials.py,为每个测试账号启动浏览器登录并提取凭证,若用户未提供测试账号,此步骤可跳过。 - GoSpider 爬虫
- 运行方式:须在沙箱环境外调用
{SKILL_ROOT}/scripts/run_gospider.py - 目标参数:单目标使用
--target {base_url};多目标使用--target {base_url1} --target {base_url2}。- 爬取目标
base_url必须严格使用用户提供的完整 URL,禁止自动转换为根目录地址(如/)、删除路径层级或仅保留域名。
- 爬取目标
- 状态检查:该检查非常关键:
- GoSpider 爬虫通常较慢,脚本运行结束后,仍然要检查状态文件
workspace/gospider_status.json,并且只有status = completed同时有输出workspace/crawl/crawled_*.json才能进入下一步;轮询查看间隔建议15秒一次或更长,期间不得重复执行脚本。 - 可以通过检查
gospider进程是否存在进行辅助判断,若进程存在,则说明后台任务仍在爬虫中,需要耐心等待状态变成completed以及输出产物。
- GoSpider 爬虫通常较慢,脚本运行结束后,仍然要检查状态文件
- 命令示例:
python {SKILL_ROOT}/scripts/run_gospider.py --target {base_url}
- 数据清洗
- 调用脚本:执行
{SKILL_ROOT}/scripts/clean_targets.py,会自动读取workspace/crawl/下全部crawled_*.json,按站点过滤外部域名、非目标 IP、静态资源,并对 URL 去重 - 固定输出:
workspace/targets.txt - 命令示例:
python {SKILL_ROOT}/scripts/clean_targets.py
4.5. 指纹汇总
- 读取以下文件,提取技术栈关键字并合并到
fingerprint.json的tech_stack字段:workspace/fingerprint.json(Phase 0 输出)workspace/admin_scan_summary.json(Phase 0.5 输出)
- 判断标准(核心原则):只提取"具体的软件产品/框架/中间件/CMS/服务器软件名称",这些名称能用于匹配 POC 库中的
fingerprint字段。不提取页面内容描述、漏洞类型名称、通用功能描述。 - 正例(应提取):
"Apache ActiveMQ Console"→ActiveMQ(具体产品名)"Jenkins Dashboard"→Jenkins(具体产品名)"GeoServer: Welcome"→GeoServer(具体产品名)"XXL-JOB 任务调度中心"→XXL-JOB(具体产品名)"Jetty(9.4.18.v20190429)"→Jetty(具体服务器软件)"nginx/1.18.0"→nginx(具体服务器软件)
- 反例(不应提取):
"SQL Injections"→ 不提取(漏洞测试页面标题,不是产品名)"XSS Test Page"→ 不提取(漏洞测试页面标题)"Error 404 - Not Found"→ 不提取(错误页面)"Welcome to DVWA"→ 不提取(靶场名称,不是真实产品)"Login Page"→ 不提取(通用功能描述)"Admin Console"→ 不提取(通用功能描述,除非能识别出具体产品如 "Jenkins Console")
- 提取规则:
- 从
fingerprint.json的web_title提取:识别标题中的具体软件产品名/框架名/中间件名 - 从
fingerprint.json的web_server提取:识别服务器软件名(如 Jetty、nginx、IIS、Apache) - 从
admin_scan_summary.json的title字段提取:识别具体软件产品名 - 智能去重:在添加新关键字前,必须先检查
tech_stack中是否已存在相同或高度相似的内容:
- 完全重复:字符串完全相同(如
Jetty已存在,不再添加Jetty) - 包含关系:新关键字是已有内容的子串或超集(如
jetty/9.4.18.v20190429已存在,不再添加Jetty;或Jetty已存在,不再添加jetty/9.4.18.v20190429) - 同一产品不同格式:如
nginx/1.18.0和nginx是同一产品,只保留一个(优先保留带版本号的) - 判断方法:将已有内容和新关键字都转为小写,检查是否存在包含关系(
a in b或b in a)
- 将去重后的关键字合并到
tech_stack,写回fingerprint.json
- 目的:汇总所有来源的技术栈信息,供后续 Agent 和报告生成使用
- 从
Phase 5:多 Agent 并行渗透测试
主流程必须通过智能体平台提供的 Multi-Agent / Subagents 能力或等效工作流能力,同时启动提示词中指定的渗透 Agent,并行执行渗透测试:
- 主流程必须先执行
python {SKILL_ROOT}/scripts/prepare_agent_findings.py --agent {agent_name},需要根据实际启用的子 agent 生成标准化骨架文件到workspace/findings/{agent_name}.json - 【强制】每个 Agent 启动后必须首先读取
{SKILL_ROOT}/agents/{agent_name}/SKILL.md,该文件定义了 Agent 的角色身份、职责范围、输入数据、检测方法论、强制执行要求、回填要求,是 Agent 行为的核心基准 - 每个 Agent 必须先建立本职责范围内的一级攻击面清单(基于已知的输入数据、文档),再递归展开二级/三级功能点,扩展攻击面清单
- 每个 Agent 必须从 HTML 表单、链接、按钮、隐藏字段、JS 请求、API 响应中继续提取子功能和隐藏入口
- 每个 Agent 必须对可疑点执行主动深入探测:基线请求、变体请求、对照请求、权限对比、参数边界、编码变体、方法变体
- 每个 Agent 必须根据业务需要执行认证态/未认证态对比:匿名、已登录、去认证重放、低权限重放、高权限对照(如有)
- 每个 Agent 不得把第一个发现或第一个漏洞当作终点,必须继续覆盖同类功能、相邻接口、同参数不同方法和认证态差异
- 所有 HTTP 请求必须使用
{SKILL_ROOT}/scripts/http_test.py;仅当漏洞更适合通过带外方式确认且无直接回显时,才使用{SKILL_ROOT}/scripts/dnslog.py - 每个 Agent 只测试自身职责范围内的漏洞类型
- 每个 Agent 只能读取并回填自己的骨架文件
workspace/findings/{agent_name}.json,不得覆盖其他 Agent 的输出;骨架中的占位值必须被真实内容覆写,发现多个漏洞时需继续向findings追加对象 - 不得基于怀疑或假设创建漏洞条目;没有真实交互证据、状态差异、回显证据或 OOB 证据时,不得创建漏洞条目
- 对于成功利用并已确认的漏洞,Agent 必须在
http_test_commands中至少记录 1 条可直接回放的http_test.py命令,且command字段中的脚本路径必须写成当前环境下的完整绝对路径,不得保留{SKILL_ROOT}占位符 - 每个 Agent 回填说明性文本字段默认使用中文,但不得翻译路径、参数名、字段名、payload、状态码、URL 中的技术片段
- 主流程必须等待全部启用的渗透 Agent 执行完成,并确认findings 文件均已被真实回填,才能进入下阶段。
Phase 5.5:攻击链分析(由 vuln-analysis-agent Agent 执行)
单站点目标场景下,主流程通过智能体平台提供的 Multi-Agent / Subagents 能力或等效工作流能力,创建一个 vuln-analysis-agent Agent(漏洞综合分析 Agent),执行 Phase 5.5 以及 Phase 5.6 步骤;当存在 2 个及以上 --target-url 时,可视为多站点目标场景,可跳过 Phase 5.5 和 Phase 5.6,直接进入 Phase 6。
vuln-analysis-agent Agent 必须完整读取 {SKILL_ROOT}/references/sub_agents/vuln-analysis-agent.md,并遵循其规范执行。
vuln-analysis-agent Agent 构建攻击链(以下攻击链仅作为示例):
- LFI + 文件上传 → RCE 链
- SSRF + Redis/FastCGI → RCE 链
- XSS + CSRF → 数据窃取链
- IDOR + Mass Assignment → 提权链
- 输出
workspace/attack_chains.json(严格按照格式规范填写)
Phase 5.6:漏洞证据复查(由 vuln-analysis-agent Agent 继续执行)
⚠️ 强制规则:该步骤仅适用于单站点目标场景;多站点目标场景可跳过。
vuln-analysis-agent Agent 必须:
- 运行自动扫描:
python {SKILL_ROOT}/scripts/verify_findings.py <workspace_dir>- 检查响应状态码(404/500 等异常)
- 检查类型专属证据特征(SQLi 必须有 SQL 报错,XSS 必须有未转义 payload 等)
- 检查响应体质量(空响应体、错误页面特征)
- 只需输出
verification.json,不要修改其它文件
单站点目标场景下,主流程仅在 vuln-analysis-agent Agent 完成 Phase 5.5/5.6 后,方可进入 Phase 6;多站点目标场景下可直接进入 Phase 6。
Phase 6:生成最终报告(主流程执行)
步骤 1:使用 Python 脚本汇总 findings目录下所有 JSON 文件
当 Phase 5.6 漏洞证据复查结束后,或多站点目标场景跳过 Phase 5.5/5.6 后,必须使用 {SKILL_ROOT}/scripts/generate_report.py 汇总 workspace/findings/*.json生成workspace/report_{timestamp}.json(工作目录内的最终 JSON 报告)。
- 基本命令格式:python {SKILL_ROOT}/scripts/generate_report.py <workspace目录> --target-url <目标URL1> [--target-url <目标URL2> ...] [可选参数]
- 必需参数:
- workspace:vibe-pentest 工作目录路径,脚本会在其中找 findings/ 子目录
- --target-url:渗透测试的目标 URL,可重复传入;传入 2 个及以上时生成多站点目标报告
- 可选参数:
- --tech-stack:识别到的技术栈列表,使用示例:--tech-stack Java Spring Boot MySQL,该值可参考
workspace/fingerprint.json内容的tech_stack字段 - --test-accounts:测试账户 JSON 数组,默认值为 [],当用户提供了测试账户时才需要使用此参数
- --tech-stack:识别到的技术栈列表,使用示例:--tech-stack Java Spring Boot MySQL,该值可参考
- 示例:
python {SKILL_ROOT}/scripts/generate_report.py workspace --target-url {base_url}
python {SKILL_ROOT}/scripts/generate_report.py workspace --target-url {base_url} --tech-stack Java Spring Nginx MySQL
python {SKILL_ROOT}/scripts/generate_report.py workspace --target-url {base_url1} --target-url {base_url2}
步骤 2:翻译说明性内容
根据用户需求检查并翻译 workspace/report_{timestamp}.json 中的说明性文本字段:vulnerabilities.RepairSuggestions、vulnerabilities.title、vulnerabilities.description、vulnerabilities.http_interactions[].label。针对这些字段,需要额外执行一次说明性文本翻译,默认翻译为中文;但不得翻译路径、参数名、字段名、payload、状态码、URL 中的技术片段。
步骤 3:使用 Python 脚本生成最终 HTML 和 Word 报告
基于步骤 1 生成的 workspace/report_{timestamp}.json,主流程调用对应的 Python 脚本生成最终 HTML 和 Word 报告。
示例:
python {SKILL_ROOT}/report_renderers/generate_html.py workspace/report_{timestamp}.json
python {SKILL_ROOT}/report_renderers/generate_word.py workspace/report_{timestamp}.json
说明:
- 执行命令后,报表会默认输出到
workspace/report_result/目录。
### Phase 7:主机漏洞扫描(可选,与 Phase 6 并行,用户没有要求可跳过执行)
⚠️ **Phase 7 与 Phase 6 并行执行,互不依赖。Phase 7 是可选的,用户没有要求主机漏洞扫描则跳过。**
**前置条件**:`session.json` 中包含 `scanner` 字段,或用户通过命令行提供 scanner 参数。
**执行**:调用 `scripts/run_vuln_scan.py` 包装脚本:
```bash
python {SKILL_ROOT}/scripts/run_vuln_scan.py --workspace <workspace_dir>
脚本自动完成:
- 从
session.json中的target_url解析 host 和 port - 从
session.json中的scanner获取漏扫系统 API 地址和 access_token - 调用
vuln_scan.py创建扫描任务 → 等待完成 → 生成报表 → 下载 zip - 将下载的 zip 复制到
workspace/vuln_scan_report.zip
Phase 1 集成:在授权确认阶段询问用户是否启用主机漏洞扫描:
- 如果启用,询问漏扫系统 API 地址和 access_token
- 将 scanner 配置写入
session.json - 如果不启用,跳过 Phase 7
HTTP 发包工具(强制规范)
主流程、所有渗透 Agent、漏洞综合分析 Agent 在需要向目标发送 HTTP 请求时,必须优先使用 {SKILL_ROOT}/scripts/http_test.py。
此工具是 vibe-pentest 技能的内置脚本,功能全面且专门为渗透测试场景优化:
- 响应瘦身:内置正则过滤 + 行/字节截断,防止大 HTML 页面灌爆 Agent 上下文
- 编码守护:自动推断 charset(从 header、body meta 标签、chardet 检测),正确处理 GBK/UTF-8/ISO-8859-1
- 性能指标:独立 DNS/TCP/TLS/TTFB 计时,盲注/时序测试必备
- 重复+聚合:
--repeat N --delay 0.5自动统计 min/avg/max - 请求概览:
--show-command输出完整请求信息,便于证据记录 - 命令回放:
--show-command输出的请求概览可整理回填到 finding 的http_test_commands[].command;回填时脚本路径必须替换为当前环境下的完整绝对路径,便于后续人工复验时直接重放
基本调用格式
python {SKILL_ROOT}/scripts/http_test.py \
--url "<URL>" \
--method <METHOD> \
--data '<PAYLOAD>' \
--headers '{"Header-Name":"value"}' \
--cookies "<COOKIE_STRING>" \
--show-command \
--show-summary \
--include-headers \
--response-max-lines 80
必读参考
详细用法(6 个渗透场景模板、全参数速查表、过滤正则模板)见:
{SKILL_ROOT}/references/http-test-usage.md
每个 Agent 在开始测试前必须读取此参考文档。
与 curl 的区别
| 功能 | http_test.py | curl |
|---|---|---|
| 响应正则过滤 | --response-filter '(error|SQL)' |
需 pipe grep |
| Token 优化 | 自动瘦身(max_lines/max_bytes) | 需手动截断 |
| 编码守护 | 多重自动检测 | 需手动识别 |
| 性能指标 | DNS/TCP/TLS/TTFB/Speed | -w 格式字符串 |
| 重复聚合 | --repeat 5 --delay 0.3 |
需 shell 循环 |
| 表单编码 | 自动推断 + URL-encode | 需手动 --data-urlencode |
禁止场景:除了一次性的简单 HEAD/OPTIONS 探测外,所有涉及 payload 注入、表单提交、API 测试、认证测试的 HTTP 请求都必须使用 http_test.py,不得使用 curl 或其他工具替代。
OOB/DNS 回调验证工具
SSRF、盲 XXE、命令注入(盲)、SQL 盲注(OOB 外带)、JNDI 注入等无回显漏洞的 OOB 验证,必须使用 {SKILL_ROOT}/scripts/dnslog.py。
此工具基于 dnslog.cn 实现 DNS 查询记录获取:
- 获取临时域名:
python {SKILL_ROOT}/scripts/dnslog.py get_domain - 查询 DNS 记录:
python {SKILL_ROOT}/scripts/dnslog.py get_records <域名> [等待秒数] - 判断标准:
status为success且record_count> 0 → 目标触发了 DNS 查询 → 漏洞 confirmed
安全规则
- 严格限制目标域名,不测试范围外的任何地址
- 不执行破坏性操作:不删除数据、不修改业务数据、不发起 DoS
- 凭证安全:如果
sessions/*.json包含敏感信息,测试完成后提醒用户删除 - 速率控制:请求间保持合理间隔,避免触发 WAF 或对服务造成影响
反幻觉规则
- 只报告实际发送过请求并收到响应的漏洞
- 每个漏洞必须有完整的 HTTP 交互证据(request + response)
- 不猜测不存在的路径或接口,所有测试目标必须来自爬取结果
- 置信度标记:
confirmed(有证据)、likely(间接证据)、potential(疑似) - 没有证据时不创建漏洞条目
- 发现漏洞不等于完成测试;必须继续覆盖同类功能、相邻接口、同参数不同方法和认证态差异
- 认证态对比不足、缺少对照请求或缺少真实 HTTP 证据时,不得标记为
confirmed