用途
该技能用于在用户要求进行安全代码审查时提供可复用的方法论。触发场景包括：分析代码安全问题、检查 OWASP 漏洞、按 CWE Top 25 审查代码等。它面向手动安全代码审查，提供步骤、漏洞分类、推荐检查清单和代码示例参考。
主要能力
- 识别攻击面：确定入口点，包括 API 端点、消息处理器、文件解析器、面向用户的表单；通过阅读路由定义和控制器注册来构建入口映射。
- 追踪数据流：从来源到汇点，跟随不可信输入（HTTP 参数、请求头、请求体、文件上传、外部 API 响应）经过所有转换，直到危险操作（数据库查询、命令执行、HTML 渲染、文件系统访问）。
- 检查信任边界穿越：在数据跨越信任边界处（客户端到服务器、服务到服务、用户输入到数据库），验证是否强制执行了验证、认证与授权。
- 应用框架检查清单：参考 references/framework-checklists.md 中的 OWASP Web/API 移动 Top 10 和 CWE Top 25，逐一核对适用类别。
- 对抗式思维：建立假设（如「我可以绕过 SSO」「我可以访问他人的保险库」），再反推使其可利用的条件。
- 映射 CWE 编号：每个发现都必须包含具体 CWE 标识、代码位置以及使其可利用的数据流。
- 按实际可利用性分类：区分实际可利用漏洞与理论风险并分别记录，据此排定优先级。
关键漏洞类别
技能列出 Bitwarden 技术栈中最常遇到的类别：
- 注入（CWE-89、CWE-78、CWE-77）：未净化输入到达 SQL 查询、操作系统命令或 LDAP 查询。应使用参数化查询，避免字符串拼接。
- 访问控制缺陷（CWE-862、CWE-287、CWE-306）：缺少授权检查、IDOR、权限提升。需在每个层验证按对象的所有权检查与角色约束。
- XSS（CWE-79）：用户输入未经编码即渲染进 HTML。在 Angular 中，避免对不可信内容使用 innerHTML 和 bypassSecurityTrust*。
- SSRF（CWE-918）：服务器端请求中使用用户可控 URL。应针对主机允许列表进行验证。
- 不安全反序列化（CWE-502）：对不可信输入启用类型处理。避免在 JSON.NET 中使用 TypeNameHandling.All。
- 路径遍历（CWE-22）：用户提供的路径到达文件系统操作。应规范化并基于基准目录进行验证。
- 加密失败：弱算法、硬编码密钥、可预测 IV。相关批准算法参见 reviewing-security-architecture 技能。
完整的框架检查清单（全部 OWASP 与 CWE 类别）见 references/framework-checklists.md；C#、TypeScript 和 SQL 的正确/错误代码示例见 references/vulnerability-patterns.md。
使用方式
按工作流分步执行：识别攻击面 → 追踪来源到汇点的数据流 → 检查信任边界穿越 → 应用框架检查清单 → 采用对抗式思维形成并反推攻击假设 → 将发现映射到 CWE ID → 按实际可利用性分类。使用时可查阅随附参考文件获取详细清单与代码示例。
对抗式审查思维
安全代码审查中的对抗式思维不同于以增强代码为目标的常规审查。做法包括：
- 建立假设，例如「我可以绕过 SSO」「我可以访问他人的保险库」「我可以从成员提升为管理员」。
- 反推攻击成功所需条件，并判断这些条件能否被伪造。
- 质疑假设：该授权检查是否总会被执行？中间件失败会怎样？令牌格式错误但未失效会怎样？
- 考虑失败模式：失败时是失败开放（不安全）还是失败关闭（安全）？
核心规则
- 先认证后授权：先确认用户身份，再检查其被允许做什么。绝不在「内部」端点跳过认证检查。
- 在信任边界处验证：任何数据跨越信任边界处都必须验证，绝不只依赖客户端验证。
- 映射 CWE ID：每个发现都必须包含具体 CWE 标识及证据（代码位置和使其可利用的数据流）。
- 实际优先于理论：区分在本系统中实际可利用的漏洞与理论风险，据此排优先级，但两者都要记录。
- 检查整条链路：漏洞不只是汇点，要从来源（用户输入）经过所有转换追踪到汇点（危险操作）。若链路被净化打断，则不可利用。
适用场景与限制
适用场景为人工主导的安全代码审查，尤其针对具有明确信任边界和数据流的代码库。资料未提供该技能的自动执行方式、具体命令、依赖环境或安装步骤；也未说明其收费方式、支持平台或版本要求，这些信息暂未提供。参考文件中 C#/.NET、TypeScript/Angular 与 SQL 的示例仅用于说明模式，不代表其他语言或框架同样适用。