mcpField
A
analyzing-code-security

analyzing-code-security

github.com/bitwarden安全162101 次安装今天更新
代码仓库

关于 analyzing-code-security

面向开发者的手动代码安全审查技能，采用对抗性流程追踪输入穿越信任边界，并将发现映射到 CWE 标识。

主要功能

  1. 01梳理攻击面
  2. 02追踪源到汇的数据流
  3. 03检查信任边界验证
  4. 04参考 OWASP 与 CWE 清单
  5. 05按可利用性评估并标注 CWE

适用场景

  1. 01审查 API 端点和文件解析器
  2. 02追踪不可信输入到敏感操作
  3. 03评估授权与验证路径

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/bitwarden/ai-plugins --skill analyzing-code-security

安装后在 Claude Code 中输入/analyzing-code-security确认已加载。

附带文件references/framework-checklists.mdreferences/vulnerability-patterns.md

详细介绍

安全审查工作流

手动进行安全代码审查时，请遵循以下步骤：

  1. 识别攻击面。 确定入口点：API 端点、消息处理器、文件解析器、面向用户的表单。阅读路由定义和控制器注册信息，绘制映射图。
  2. 追踪从源到汇的数据流。 跟踪不可信输入（HTTP 参数、标头、请求正文、文件上传、外部 API 响应）经过所有转换后，如何到达危险操作（数据库查询、命令执行、HTML 渲染、文件系统访问）。
  3. 检查跨越信任边界的情况。 每当数据跨越信任边界（客户端→服务器、服务→服务、用户输入→数据库）时，都要验证是否实施了校验、身份验证和授权。
  4. 使用框架检查清单。 查阅 references/framework-checklists.md，了解 OWASP Web/API/Mobile Top 10 和 CWE Top 25。对照正在审查的代码，检查每个适用类别。
  5. 采取对抗性思维。 提出假设（例如，“我可以绕过 SSO”“我可以访问其他用户的密码库”），然后反向推理，找出哪些条件会使其可被利用。
  6. 将发现映射到 CWE ID。 每项发现都必须包含具体的 CWE 标识符、代码位置，以及使漏洞可被利用的数据流。
  7. 按实际可利用性分类。 区分实际可利用的漏洞与理论风险。按优先级处理，并记录两者。

主要漏洞类别

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。

对抗性审查思维

进行安全代码审查时，应采取对抗性思维——这不同于旨在强化代码的常规代码审查。

如何进行对抗性思考：

  1. 提出假设 — 例如，“我可以绕过 SSO”“我可以访问其他用户的密码库”“我可以从成员提升为管理员”
  2. 反向推理 — 攻击要成功，需要满足哪些条件？这些条件能否被伪造？
  3. 质疑假设 — 是否总会执行该授权检查？中间件失效时会发生什么？如果令牌格式错误但并非无效，又会怎样？
  4. 考虑失效模式 — 出现故障时会发生什么？系统会故障开放（不安全）还是故障关闭（安全）？

关键规则

  • 先认证，再授权。 始终先验证用户的身份，再检查其权限。切勿在“内部”端点跳过身份验证。
  • 在信任边界处进行验证。 每个数据跨越信任边界的位置（客户端→服务器、服务→服务、用户输入→数据库）都必须进行验证。切勿仅依赖客户端验证。
  • 将发现映射到 CWE ID。 每项发现都必须包含具体的 CWE 标识符及证据：代码位置，以及使其可被利用的数据流。
  • 注重实际风险，而非理论风险。 区分在当前系统中可实际利用的漏洞和理论风险，并据此确定优先级，但两者都要记录。
  • 检查完整链路。 漏洞不只是危险操作的接收点——要从源头（用户输入）追踪经过所有转换直至接收点（危险操作）。如果链路被清理操作中断，则该问题不可被利用。

其他资源

参考文件

如需查看详细清单和代码示例，请参阅：

  • references/framework-checklists.md — OWASP Web Top 10、API Top 10、Mobile Top 10（2024）、CWE Top 25 查询表
  • references/vulnerability-patterns.md — C#/.NET、TypeScript/Angular 和 SQL 的正确/错误代码示例

评论

支持 Markdown