wgpsec/report-generate

渗透测试报告生成方法论

报告是渗透测试的最终交付物——再厉害的攻击，如果报告写不好，客户看不懂，等于白做。

数据采集

先收集所有已有数据：

• get_store_stats — 整体统计
• evidence_list（按类型筛选）— 资产清单
• list_vulns — 漏洞列表
• evidence_list + evidence_read（筛选凭据类型）— 凭据（脱敏后放入报告）

报告结构模板

1. 执行摘要（1 页，给管理层看）

用非技术语言概述：

• 评估范围和时间
• 一句话结论：整体安全状况如何（如"发现 3 个严重漏洞，攻击者可远程获取服务器完全控制权"）
• 关键数字：资产数量、漏洞数量（按等级分布）
• 最紧急的行动项

2. 评估范围与方法

• 目标清单（域名/IP/应用）
• 测试类型（黑盒/灰盒/白盒）
• 使用的方法论和工具
• 限制条件（时间、范围排除）

3. 发现总览

漏洞统计图表：

严重: ■■ 2
高危: ■■■ 3
中危: ■■■■■ 5
低危: ■■■ 3
信息: ■■■■■■ 6

4. 漏洞详情（核心部分）

每个漏洞按以下结构描述：

[严重] SQL 注入 — 用户搜索功能

• 位置：https://target.com/search?q=
• 描述：搜索参数未经过滤直接拼入 SQL 查询，攻击者可读取/修改/删除数据库内容
• 影响：可获取所有用户数据（含密码哈希）、可读取服务器文件
• 复现步骤：
  1. 访问 https://target.com/search?q=' OR 1=1--
  2. 页面返回所有记录（正常应只返回匹配项）
  3. 使用 UNION SELECT 可提取 users 表
• 修复建议：使用参数化查询（Prepared Statement），禁止字符串拼接 SQL

5. 风险评级标准

使用 CVSS 3.1 或简化版：

| 等级 | CVSS | 典型场景 | |------|------|----------| | 严重 | 9.0-10.0 | RCE、SQL注入可获取shell、认证完全绕过 | | 高危 | 7.0-8.9 | 敏感数据泄露、权限提升、任意文件读取 | | 中危 | 4.0-6.9 | 存储型XSS、CSRF、信息泄露 | | 低危 | 0.1-3.9 | 反射型XSS、目录列表、版本泄露 | | 信息 | 0 | 安全配置建议、最佳实践偏离 |

6. 修复建议优先级

按修复紧迫性排序：

1. 立即修复：严重和高危漏洞
2. 计划修复：中危漏洞（下个版本）
3. 择机改进：低危和信息级

7. 附录

• 工具列表和版本
• 详细测试时间线
• 原始扫描数据（可选）

写作原则

• 可复现：技术人员看完复现步骤能自己验证；小型 PoC 可放在复现步骤，较长 PoC 放附录并在正文引用
• 可理解：管理层看完执行摘要能理解风险；漏洞影响要落到业务后果，而不是只写技术名词
• 可操作：修复建议具体到代码/配置级别
• 不夸大：客观描述风险，不为了显得重要而提升等级
• 可交付：最终交付优先使用 PDF；不要把可编辑的 Word/Markdown/LaTeX 作为唯一交付物
• 避免主观情绪化表述，保持专业

交付质量检查

敏感信息脱敏

• 对密码、Token、身份证件、个人照片、客户数据做不可逆遮盖，避免只用半透明模糊
• 截图导入文档前先在图片文件中完成遮盖；不要依赖 Word 里的覆盖图形，原图可能仍保存在文档包内
• 对凭据只保留必要前后缀用于定位，例如 AKIA...ABCD

截图规范

• 截图只保留能证明漏洞的最小区域，确保命令、URL、状态码和关键响应可读
• 避免暗色透明终端；报告经常会被打印或压缩，低对比度截图会失真
• 每张图加标题或说明，图中高亮关键证据
• 命令行截图应包含实际命令；纯输出截图不利于复现

文档卫生

• 列表要去重并排序（按严重度、域名、IP、端口或时间线）
• 避免“多个”“一些”等模糊数量，能量化就写具体数量
• 不要把客户敏感数据发送到不受控的在线 LLM；如需辅助写作，优先使用本地模型或先脱敏
• 交付前检查拼写、链接、图片清晰度、目录、页眉页脚和附件是否完整