渗透测试

让有技能的人如真实对手般攻击应用，找自动化工具漏的链。

为什么

自动扫描器（SAST、DAST）找单个漏洞——这里 SQL 注入、那里缺头。人工渗透测试师找链: 泄露会话令牌的 IDOR、使能账户接管、给管理员访问退款到攻击者卡的账单端点。这些多步利用链是真实攻击者用的，无自动工具能合成它们因需理解应用业务逻辑非仅技术模式。渗透测试是安全态势最现实验证，报告是合规（SOC 2、PCI-DSS）和优先修复的具体证据。它贵所以周期性做非持续。

何时使用

大发布前、合规审计前（SOC 2、PCI-DSS）、面向互联网应用至少每年。重大架构变更后也做。修复后重测确认漏洞真关闭。

如何做

1. 精确界定范围
   - 列范围内 URL、功能、用户角色
   - 定交战规则: 黑盒（无源）、灰盒（些信息）、白盒（全源）
   - 提供有真实（匿名化）数据的测试环境非生产

2. 选测试者
   - 外部公司（独立、广经验、贵）用于合规级报告
   - 内部红队（便宜、更多上下文、但可能漏新技术）用于持续验证
   - 漏洞赏金（HackerOne、Bugcrowd）用于面向互联网应用的持续众包测试

3. 交战期间（1-2 周）
   - 测试者探测应用、链发现、试图达定义目标（管理员访问、数据外泄）
   - 每日沟通: 讨论发现、澄清范围、避免重复工作
   - 测试者可用任何工具（Burp、自定义脚本、社会工程若在范围内）

4. 收报告并分类
   - 每个发现: 描述、复现步骤、严重性、业务影响、修复
   - 按风险 = 严重性 × 可利用性 × 业务影响分类
   - 危 24-48 小时内修、高一周内、中一个迭代内

5. 修复后重测并维护报告
   - 让测试者重验每个修复——"修复"实际不关漏洞很常见
   - 保留报告作审计证据；在追踪器中追踪发现到关闭

示例

# 渗透测试报告摘录（简化）
发现 P-03: 通过 IDOR + JWT 重用的账户接管
  严重性: 危急
  复现步骤:
    1. 作为用户 A，记你的 JWT: eyJhbGc...
    2. GET /api/users/123/sessions — 返回 A 的会话（A 是用户 123）
    3. 作为用户 B（不同账户），用 B 的 JWT 发同请求
       但把 URL 改为 /api/users/123/sessions
    4. 服务器返回用户 A 的活跃会话（IDOR——无拥有检查）
    5. 从响应取 A 的会话 cookie，设到 B 的浏览器
    6. B 现以 A 登录——完整账户接管
  业务影响: 任何用户可接管任何其他用户账户，
    访问其支付方式并购买。
  修复: 给 /api/users/:id/sessions 加拥有检查——
    返回会话前验 req.user.id === Number(req.params.id)。
  状态: v2.3.1 修复，测试者 2024-04-15 重测——确认关闭。

# 此链（IDOR → 会话窃取 → 接管）不会被 SAST 或 DAST
# 单独发现——需理解会话管理的业务逻辑。

常见问题

⚠为省钱把渗透测试范围定太窄（仅登录页）——测试者啥也找不到因敏感端点超范围，报告给应用安全的虚假信心。
⚠把渗透测试当一次性合规勾选——报告归档、危急修了、但中从不处理，同样漏洞下次测试再现因根因未修。
⚠不给测试者现实测试环境——他们对空数据库测漏仅真实数据量才现的漏洞（分页 bug、搜索注入）。
⚠为省钱跳重测——"修复"实际不关漏洞很常见（开发者补了一个入口点但漏了三个），仅重测确认修复完整。

最佳实践

✓把渗透测试范围覆盖所有用户角色和最高风险功能（认证、支付、数据访问）——窄范围啥也找不到的测试是浪费钱和假信号。
✓提供专用测试环境含真实匿名化生产数据使测试者能找依赖数据形状的漏洞（分页、搜索、批量操作）。
✓按风险（严重性 × 可利用性 × 业务影响）分类发现非仅严重性——支付端点上的中 IDOR 比营销页上的高 XSS 风险更高。
✓修复后始终重测——付重测周期让测试者验每个修复，因不完整修复（补几个入口点之一）是漏洞复发最常见原因。