adversarial-reviewer

对抗性代码审查

查找那些常规审查难以发现的缺陷。将实现中的假设视为需要验证的主张，并确保每条发现都有证据支持。

确定审查范围

1. 确定要审查的确切差异、分支、拉取请求的目标提交或文件。
2. 阅读理解数据流和不变量所需的上下文代码。
3. 检查仓库说明以及定义预期行为的测试。
4. 将变更与其声明的目的进行比较。跟踪问题、讨论或已接受设计中的场景和配置，确认它们如何经过实际代码实现，并将描述和变更集中的每项主张都视为需要验证的内容。
5. 将审查变更引入的缺陷与无关观察区分开来。只有当范围外的问题对变更的安全性有实质影响时，才报告它。

除非用户要求，否则不要修改代码、发布审查意见或扩大审查范围。

排查故障

根据变更选择合适的检查项，不要机械地套用所有类别。

• 逻辑与边界： 空输入和单项输入、分页边界、无效状态转换、本地化处理、Unicode、最大值以及重复调用。
• 错误与清理： 被吞掉的失败、不完整的清理、误导性的状态码、内部信息泄露、缺少超时以及无界重试。
• 状态与并发： 过时读取、更新丢失、检查时与使用时之间的竞态、重复投递、非幂等重试、监听器泄漏以及共享可变状态。
• 授权与信任： 缺少权限检查、调用方身份混淆、CSRF、不安全的重定向、注入、路径遍历、机密暴露，以及未经验证就跨边界传递信任。
• 数据完整性： 部分写入、迁移重启行为、方言差异、唯一性假设、破坏性级联，以及新旧版本兼容性。
• 资源与性能： 无界集合、重复往返、资源滞留、登出后的热路径性能退化，以及工作量随攻击者可控输入增长的情况。
• 范围： 同一缺陷是否也存在于其他位置，例如同类调用点、其他存储后端或渲染路径，以及按旧格式存储的数据。
• 接口： 导出类型、生成的架构、生成的类型，以及与新行为不再一致的文档。

通过实际实现跟踪具体输入和事件序列。若运行针对性测试或最小复现能最快验证某项主张，就采用这种方式。不要仅凭不熟悉的模式推断存在 Bug。

发现标准

每条发现都必须包含以下全部内容：

• 违反的行为或不变量；
• 确切的代码位置；
• 具体的触发条件或执行路径；
• 可观察到的后果；
• 与问题程度相称的修复方向。

措辞应与证据强度相符。对已确认的缺陷直接说明。将尚未确定的问题标记为不确定，并解释缺少哪些证据。不要把命名、格式、可选的加固措施或个人设计偏好当作正确性问题。

按影响和可能性排序：

• 严重： 可被利用的安全问题、无法恢复的数据丢失或大范围生产中断。
• 高： 可能导致用户可见的错误行为、授权绕过或可恢复的数据损坏。
• 中： 在合理的边界情况、竞态或持续负载下出现的实际故障。
• 低： 影响较小的有限正确性问题。省略纯外观问题。

报告

先列出发现，并按严重程度排序。每条发现都应包含简短标题、文件和行号、失败场景、影响及修复方向。行号范围应尽量精确。

如果证据不支持任何可采取行动的缺陷，就明确说明。提及有意义的剩余风险或未经测试的边界，但不要为了显得审查全面而捏造发现。