thinking-red-team

红队

对你获准评估的系统进行对抗性安全审查。在外部攻击者动手前先行攻击，但只报告你确实能够攻破的问题：每项发现都必须有具体的利用路径，并检查所提修复是否能堵住该路径。

适用场景

• 审查你控制且获准探测的代码、身份验证、授权、API、数据处理或基础设施。
• 对处理身份验证、资金、个人数据或特权操作的系统进行上线前加固。
• 检查某一特定漏洞类型（注入、XSS、IDOR、身份验证绕过、SSRF、机密信息泄露等）是否存在可实际利用的路径。
• 验证声称有效的防护措施是否真的能阻止攻击，而不只是让扫描器不再报警。

不适用场景

• 未获准攻击目标——立即停止；不得探测你不拥有或未获书面许可测试的系统。
• 没有可复现利用路径的推测性“最佳实践”建议——删除；这类内容不算发现。
• 计划、策略或决策压力测试——使用事前验尸（分析计划如何失败）或钢人论证（针对决策构建最有力的反方论据）。
• 没有安全目标的架构韧性评估——使用 systems 或 pre-mortem。
• 仅凭扫描器输出撰写报告——扫描结果只是线索；红队评估必须提供利用路径。
• 非安全领域的根因分析或假设定位——使用 scientific-method 或 five-whys-plus。

流程

1. 确认授权和目标。 说明目标、允许范围、范围外资产、成功条件（例如，未经授权读取数据、权限提升）和停止规则。授权不明确时，拒绝执行或缩小范围。
2. 构建威胁模型。 列出攻击者类型（匿名外部人员、已验证身份的用户、特权内部人员）及其在现实访问条件下的目标。没有攻击者和目标的攻击只是噪声。
3. 梳理攻击面。 列出入口点和信任边界：公开端点、身份验证流程、API、上传功能、管理界面、作业、webhook、机密信息和数据存储。注明暴露情况和所需权限。
4. 追踪利用路径。 对每个高价值攻击面尝试具体滥用：操纵输入、授权缺口、令牌／会话滥用、注入、SSRF、IDOR、批量赋值、绕过速率限制、机密信息泄露。记录确切步骤和观察到的行为。
5. 执行防伪门槛。 只有能完整描述“入口点 → 按顺序执行的步骤 → 在此代码／配置中实现的影响”时，才保留一项发现。不完整的路径应删除，不得列为“信息性”发现。
6. 评定严重程度并尝试绕过防护。 评估影响和可利用性。对于每项相关控制措施（速率限制、验证、会话检查），尝试现实可行的绕过方式，并记录防护是否有效。
7. 提出并验证缓解措施。 对每项保留的发现，给出最精简的具体修复方案，并说明如何重新测试以确认路径已被堵住。优先选择能消除利用前提的修复方案。当范围内的攻击面均已覆盖，或授权／预算用尽时停止；没有发现问题也属于有效结果。

输出

Target/scope: <in | out | goal | authorization>
Threat model: <actors, access, goals>
Attack surface: <entry points + trust boundaries>
Findings (only complete paths):
  - Title | Severity
    Entry: <endpoint/param/file>
    Steps: <1..n>
    Impact: <realized effect>
    Bypass attempts: <control → result>
    Mitigation: <minimal fix>
    Re-test: <how to confirm closed>
Summary: <kept count; dropped speculative count>

验证

• 对缺少入口点、步骤或实际影响的发现进行证伪；将“可能存在漏洞”视为非发现。
• 在授权范围内的攻击面全部检查完毕，或重新测试确认缓解措施已堵住相关路径后停止。
• 防止过度应用：不要用最佳实践清单凑数；不要将此技能用于非安全领域的计划评议；未经授权不得发起攻击。