owasp-security-code-review

OWASP 安全代码审查

使用此技能执行人工安全审查，从架构入手，沿着具体执行路径进行检查。如果有明显适用的特定语言、框架、CI、云或基础设施审查技能，请优先使用；此技能用于基线覆盖和跨领域审查逻辑。

审查原则

• 报告问题前先建立威胁模型：识别参与者、资产、信任边界、权限级别和攻击者可控的输入。
• 将入口点、身份判定、权限变更和敏感数据流动作为主要审查锚点。
• 从源头开始，经过各种转换和防护，直到汇点或安全决策，端到端确认问题。
• 区分已确认的漏洞、可疑模式和未解决的问题。
• 宁可报告少量证据充分的问题，也不要罗列推测性问题。
• 明确记录覆盖情况：已审查的区域、跳过的区域，以及影响可信度的假设。
• 对每个已确认的问题，始终在审查工作区中创建或更新一个独立的 poc_<finding_slug>.py 文件。

参考资料

• 常规审查时使用以下本地参考文件。只有用户要求核实来源或获取最新指导时，才查阅 OWASP 上游页面。
• 审查输入处理、注入、身份验证、授权、反序列化、XML 或加密实现模式时，请阅读 references/common-vulnerability-patterns.md。
• 梳理多步攻击路径、审查关键业务工作流或将威胁模型转化为具体代码路径时，请阅读 references/attack-trees.md。
• 有关 OWASP 审查工作流、源到汇点的追踪，以及基线审查与差异审查提示，请阅读 references/owasp-secure-code-review.md。
• 有关输入和注入专项模式，请阅读 references/owasp-input-validation.md、references/owasp-sql-injection.md、references/owasp-xss.md、references/owasp-file-upload.md、references/owasp-os-command-injection.md 和 references/owasp-nosql-security.md。
• 有关身份和访问控制模式，请阅读 references/owasp-authentication.md、references/owasp-session-management.md 和 references/owasp-authorization.md。
• 有关序列化、XML 解析器和加密存储模式，请阅读 references/owasp-deserialization.md、references/owasp-xxe.md 和 references/owasp-cryptographic-storage.md。

审查流程

1. 审查架构中的安全反模式。

   • 清点组件、语言、框架、存储、外部集成、特权任务和部署边界。
   • 识别信任假设，例如信任内部网络、共用管理员路径、租户数据混杂、不安全的插件或反序列化入口、动态代码执行，以及持有密钥的服务。
   • 记录安全控制集中实施的位置，以及可能绕过这些控制的其他路径。

2. 分析入口点和输入验证。

   • 列举 HTTP/RPC 路由、GraphQL 解析器、消息消费者、Webhook、CLI 命令、定时任务、文件导入、反序列化器和配置输入。
   • 追踪解析、规范化、规范形式转换、模式检查、类型检查、大小限制、允许列表及拒绝行为。
   • 查找其他编码形式、重复参数、路径混淆、对象绑定问题，以及危险汇点之后才执行的验证。

3. 验证身份验证和授权。

   • 梳理用户、服务和后台任务流程中身份的建立、刷新、传递和撤销方式。
   • 检查会话、令牌、API 密钥、mTLS 和服务账户验证方面的假设。
   • 验证每次读取、写入、导出和状态转换是否都执行了所需的角色、租户、所有权和对象级检查，包括备用路由和异步处理程序。
   • 测试中间件、策略引擎或上游身份数据缺失或格式错误时是否会默认放行。

4. 追踪数据流。

   • 追踪不可信数据流向 SQL/NoSQL 查询、模板、文件系统路径、归档文件、重定向、出站请求、命令执行、日志、序列化、缓存和客户端响应的路径。
   • 追踪凭据、令牌、个人数据和密钥等敏感数据在存储、遥测、错误、导出和第三方边界中的流转。
   • 记录每条路径上的清理、编码、转义、参数化和权限边界；验证每项控制措施是否适用于相应的接收端。

5. 分析业务逻辑。

   • 将关键工作流建模为状态和不变量：审批、付款、邀请、密码重置、账户恢复、配额、权益、租户隔离和管理员操作。
   • 检查重放、竞争、顺序、过期状态、重复消费、部分失败和 TOCTOU 行为。
   • 查找跳过步骤、重复使用凭证、更改标识符，或通过意外渠道调用特权状态转换的方法。

6. 审查加密实现。

   • 识别密码哈希、加密、签名、MAC、随机数、密钥派生、密钥存储、证书验证和令牌构造。
   • 验证是否使用现代密码原语和安全参数，是否确保 nonce/IV 唯一性，并检查适用场景下的常量时间比较、密钥隔离、轮换和失败行为。
   • 将自定义加密、硬编码密钥、弱随机数、禁用 TLS 验证，以及未签名或仅部分验证的令牌列为优先审查项。

7. 验证错误处理。

   • 检查身份验证、授权、验证和事务边界上的错误是否会安全失败。
   • 审查异常吞噬、回退行为、重试、部分提交、默认值、详细响应、堆栈跟踪和包含机密的日志。
   • 确认可观察到与安全相关的失败，同时不会泄露敏感细节。

8. 审查配置和部署。

   • 检查调试模式、CORS、可信代理、主机验证、Cookie 标志、安全标头、日志记录、功能标志和机密加载的默认值及环境变量解析方式。
   • 在这些内容属于审查范围时，审查容器/运行时权限、文件系统权限、网络暴露、云/IAM 绑定、CI/CD 机密、构建时替换，以及生产与开发环境之间的偏差。
   • 找出不安全的默认配置，避免安全部署依赖未记录的运维人员操作。

9. 构建 PoC 文件。

   • 为每项已确认的问题创建或更新一个独立的 poc_<finding_slug>.py 文件。
   • 确保每个 PoC 都按步骤推进：打印或实现编号步骤，涵盖前提条件、身份验证或材料获取、触发、影响验证和清理指南。
   • 发送请求前，说明攻击者所处位置、所需权限、凭据或证书、环境依赖，以及任何尚未证实的前提条件。
   • 默认采用干运行或无害标记；只有在显式传入标志时才执行会改变状态的验证。
   • 如果某项发现没有安全可运行的路径，仍需为其创建对应的 PoC 脚手架，并说明缺少的前提条件或不安全步骤。
   • 使用语法检查和干运行验证每个脚本，然后记录已执行和未执行的实时步骤。

发现标准

仅当审查能够说明以下内容时，才报告发现：

• 受影响的代码路径及文件和行号
• 攻击者可控的输入或被违反的信任假设
• 缺失、被绕过或不正确的控制措施
• 可触达的影响及所需前提条件
• 具体的修复方向
• 有针对性的回归测试或验证步骤

如果某个疑虑缺少完整路径，或依赖缺失的运行时上下文，应将其标记为待确认问题或覆盖缺口，而不是已确认漏洞。

输出

按严重程度排序，并以发现项开头。每项发现均须包含 Severity、Location、Issue、Exploit Path、Impact、Remediation、Test 和 PoC Requirements。

对于每项已确认的发现，在报告中引用相应的 poc_<finding_slug>.py 工件，并说明最低攻击者权限、所需权限或凭据、环境条件、安全的默认行为以及示例调用方式。

列出发现后，添加“待确认问题 / 假设”和“覆盖情况”部分。如果没有已确认的发现，须明确说明，并仍然列出已审查的范围、未解决的风险和测试缺口。