find-bugs

查找 Bug

审查此分支中的更改，查找 Bug、安全漏洞和代码质量问题。

适用场景

• 你需要重点审查 Bug、安全问题或存在风险的代码更改。
• 任务是审计当前分支差异，而非实现新行为。
• 你希望采用结构化审查流程，根据检查清单核验已更改的文件。

阶段 1：完整收集输入

1. 将请求中的基准提交和头部提交确认为经过验证的提交 SHA。必要时检查远程分支或默认分支；不要假定本地分支没有过时。使用分别加引号的已验证引用，通过 git diff "$BASE_SHA...$HEAD_SHA" -- 查看完整的分支差异。若暂存和未暂存的更改也在范围内，则一并纳入；保留当前检出状态。
2. 如果输出被截断，则逐个读取已更改的文件，直到看过每一处更改
3. 继续之前，列出此分支中所有已修改的文件

阶段 2：攻击面梳理

对每个已更改的文件，识别并列出：

• 所有用户输入（请求参数、标头、正文、URL 组件）
• 所有数据库查询
• 所有身份验证／授权检查
• 所有会话／状态操作
• 所有外部调用
• 所有加密操作

阶段 3：安全检查清单（逐个文件检查每一项）

• 注入：SQL、命令、模板、标头注入
• XSS：模板中的所有输出是否都经过正确转义？
• 身份验证：所有受保护的操作是否都进行了身份验证检查？
• 授权／IDOR：是否验证了访问控制，而不仅仅是身份验证？
• CSRF：状态更改操作是否受到保护？
• 竞态条件：任何先读后写模式中是否存在 TOCTOU 问题？
• 会话：会话固定、过期时间、安全标志？
• 密码学：是否使用安全随机数和适当的算法？日志中是否泄露机密？
• 信息泄露：错误消息、日志、时序攻击？
• 拒绝服务：无界操作、缺少速率限制、资源耗尽？
• 业务逻辑：边界情况、状态机违规、数值溢出？

阶段 4：验证

对每个潜在问题：

• 检查已更改的代码中是否已在其他位置处理该问题
• 搜索是否有覆盖此情形的现有测试
• 阅读周边上下文，确认问题确实存在

阶段 5：结论前审计

定稿前，必须：

1. 列出审查过的每个文件，并确认已完整阅读
2. 列出每项适用的检查清单项目，并将其标记为审查范围内已验证、有发现、不适用或未验证；未发现问题并不能证明安全
3. 列出你无法完全验证的方面及其原因
4. 只有完成上述步骤后，才能给出最终发现

输出格式

优先级：安全漏洞 > Bug > 代码质量

跳过：风格／格式问题

对于每个问题：

• 文件:行号 - 简要描述
• 严重性：严重／高／中／低
• 问题：说明问题所在
• 证据：具体触发条件、可达路径，以及观察到的或推理出的影响；仅缺少测试不足以证明存在 Bug
• 修复：给出具体建议
• 参考资料：适用时提供 OWASP、RFC 或其他标准

如果没有发现显著问题，请如实说明，不要凭空编造问题。

对于仅要求审查的请求，只报告发现，不要更改代码。明确要求同时审查和修复时，才授权进行范围内的修复和验证；请区分发现与已完成的修复。

示例

用户请求：

审查当前分支差异中的真实 Bug、安全问题和回归问题，并引用确切的文件和行号。

限制

• 仅当任务明确符合上述范围时，才使用此技能。
• 不要将输出视为环境特定验证、测试或专家审查的替代品。
• 如果缺少必要的输入、权限、安全边界或成功标准，请暂停并请求澄清。