sentry-security

Sentry 安全审查

通过检查曾在此代码库中导致真实漏洞的模式，发现 Sentry 代码中的安全漏洞。

此技能专用于 Sentry。它编码了来自过去一年发布的 37 个真实安全补丁中的模式——不是通用的 OWASP 理论。

范围

审查用户提供的代码（文件、diff 或端点）。根据需要研究代码库，以在报告前建立信心。

仅报告 HIGH 和 MEDIUM 置信度的发现。不要报告理论性问题。

置信度	标准	行动
HIGH	已追踪流程，确认不存在检查	报告并提供修复
MEDIUM	检查可能存在但无法确认	报告为需要验证
LOW	理论性或在其他地方已缓解	不报告

第 1 步：对代码进行分类

确定你正在审查的内容，并加载相关参考。

代码类型	加载参考
API 端点（继承自 *Endpoint）	references/endpoint-patterns.md
序列化器或表单字段	references/serializer-patterns.md
邮件模板或 HTML 渲染	references/output-sanitization.md
Token、OAuth 或会话处理	references/token-lifecycle.md
角色或权限逻辑	references/privilege-escalation.md

如果代码跨越多个类别，请加载所有相关参考。

始终加载 references/enforcement-layers.md——它记录了在 Sentry 的请求生命周期中安全检查可以合法存在的位置。任何层中的检查都算作执行。

第 2 步：检查前 6 大漏洞类别

这些按过去一年真实补丁中的出现频率排序。

检查 1：跨组织对象访问（IDOR）——去年 9 个补丁

最常见的漏洞。端点接受请求中的 ID，但没有按 URL 中的组织限定查询范围。

对来自请求的每个 ID 追踪此流程：

1. Where does the ID enter? (query param, request body, URL kwarg)
2. Where is it used in an ORM query?
3. Between (1) and (2), is the query scoped by organization_id or project_id
   from the URL (NOT from the request body)?

危险信号：

• Model.objects.get(id=request.data["something_id"])——没有组织范围
• Model.objects.filter(id=request.GET["id"])——没有组织范围
• 直接使用来自请求正文/查询的 project_id，而没有 Project.objects.filter(id=pid, organization_id=organization.id)
• 端点继承 OrganizationEndpoint，但处理程序方法不接受或不使用 organization 参数

安全模式：

• 查询包含 organization_id=organization.id，其中 organization 来自 convert_args()
• 使用 self.get_projects()，它内部按组织限定范围
• 对象通过由 convert_args() 解析的 URL kwargs 获取
• 未限定范围的查询只是一个仅引发错误的守卫（从不返回数据），并且 同一流程中的下游查询确实是按组织限定范围的，并引发相同的错误—— 没有差异行为意味着没有信息泄露

检查 2：缺少授权检查——去年 10 个补丁

端点或序列化器执行敏感操作，而未验证用户是否具有权限。

检查：

• 端点是否继承自正确的基类？（OrganizationEndpoint、ProjectEndpoint 等）
• 它是否声明了 permission_classes？如果没有，它会继承基类默认值——验证这是否合适。
• 对于引用其他对象的序列化器字段：它们是否验证用户能够访问这些对象？
• 对于 Django 视图（不是 DRF）：是否有 @login_required 或等效项？

检查 3：权限提升 / 角色滥用 — 去年 3 个补丁

用户可以分配所有权、修改角色，或将其访问权限提升到超出其角色允许的范围。

检查：

• 所有者/被分配人字段：使用 OwnerActorField（验证成员资格），而非 ActorField（允许任意 actor）
• 角色修改端点：验证请求用户的角色 >= 目标角色
• 团队分配：验证用户是目标团队的成员（或具有 team:admin）

检查 4：令牌 / 会话安全 — 去年 5 个补丁

令牌生命周期缺口导致未授权访问。

检查：

• 令牌刷新：在授予刷新之前，是否检查了应用的活跃状态？
• 组织级令牌：是否要求并验证 organization_id？
• 成员状态：在授予令牌之前，是否检查了成员的启用/禁用状态？
• 模拟：被模拟的会话是否受到速率限制？

检查 5：输出净化（XSS/HTML 注入）— 去年 4 个补丁

用户可控字符串在电子邮件、markdown 或 HTML 中不安全地渲染。

检查：

• 电子邮件模板中使用的用户显示名称、团队名称、组织名称：是否已净化？
• Markdown 渲染：是否允许自定义 CSS 或 HTML 通过？
• 模板中的 format_html() 与字符串拼接
• 对用户输入调用 mark_safe()

检查 6：认证/MFA 缺口 — 去年 3 个补丁

认证状态不一致。

检查：

• 移除身份验证器时：恢复码是否已清理？
• CSRF 令牌处理：是否在标签页/窗口之间同步？
• 会话失效：移除认证因素时是否正确使会话失效？

如果没有检查产生潜在发现，请停止并报告零发现。不要为了填充报告而编造问题。当代码没有与这些模式匹配的漏洞时，空结果就是正确的输出。

步骤 3：追踪完整的强制执行链

对于每个潜在发现，端到端追踪完整的请求流。不要在认证类处停止 — 继续跟进到端点处理器，然后跟进到它委托的任何业务逻辑类（例如 Validator、Refresher、GrantExchanger）。

1. Authentication class   → does authenticate() or authenticate_token() enforce the check?
2. Permission class       → does has_permission() enforce it?
3. convert_args()         → does has_object_permission() / determine_access() enforce it?
4. Access module          → does from_rpc_auth() or from_request() enforce it?
5. Handler method         → does the endpoint handler enforce it?
6. Business logic classes → do downstream classes (Validator, etc.) enforce it?
7. Serializer             → do validate_*() methods enforce it?

任何一层的检查都是强制执行。 在标记为 HIGH 之前，使用 enforcement-layers.md 中的清单确认该检查在所有层中都不存在。

如果你无法确认该检查在每一层都不存在，请将该发现标记为 MEDIUM（需要验证），而非 HIGH。

令牌发放的跨流强制执行： 对于令牌/凭证发放流，还要检查已发放的凭证是否在使用时刻被阻止（例如，determine_access() 在相关范围内的所有端点拒绝它）。根据强制执行范围进行分类：

• 集中式强制执行（检查在被受影响范围内所有端点继承的权限类中运行）→ 凭证实际上无效 → LOW（不报告）
• 分散式强制执行（只有部分端点或序列化器检查，其他可能不检查）→ MEDIUM（报告为需要验证）

参见 enforcement-layers.md 的 "Cross-Flow Enforcement"。

非 DRF 视图： OAuth 视图是普通的 Django 视图 — 7 层 DRF 模型不适用于视图本身。检查视图自身的装饰器和处理器逻辑。但这些视图发放的令牌稍后会在 DRF 端点使用，那里适用完整的强制执行链。

步骤 4：报告发现

## Sentry Security Review: [Component]

### Findings

#### [SENTRY-001] [Title] (Severity: Critical/High/Medium)

- **Category**: [IDOR | Missing Auth | Privilege Escalation | Token | XSS | Auth/MFA]
- **Location**: `path/to/file.py:123`
- **Confidence**: HIGH — confirmed through code tracing
- **Issue**: [What the vulnerability is]
- **Trace**:
  1. [Step-by-step trace showing how the vulnerability is reached]
- **Impact**: [What an attacker could do]
- **Fix**:
  ```python
  [Code that fixes the issue — must enforce, not document]
  ```

• 先例：[适用的类似过往修复，例如 "Similar to #104990 PromptsActivity IDOR"]

需要验证

[MEDIUM 置信度项目，并说明需要验证的内容]

未审查

[审查范围之外的领域]

Fix suggestions must include actual enforcement code. Never suggest a comment or docstring as a fix.