sentry-security

Sentry セキュリティレビュー

このコードベースで実際の脆弱性を引き起こしてきたパターンをチェックすることで、Sentry のコードに潜むセキュリティ脆弱性を見つけます。

このスキルは Sentry 固有のものです。一般的な OWASP の理論ではなく、過去 1 年間に出荷された 37 件の実際のセキュリティパッチから得られたパターンをエンコードしています。

スコープ

ユーザーが提供したコード（ファイル、diff、またはエンドポイント）をレビューします。報告する前に確信度を高めるため、必要に応じてコードベースを調査してください。

報告するのは HIGH および MEDIUM の確信度の検出事項のみです。理論上の問題は報告しないでください。

確信度	基準	アクション
HIGH	フローを追跡し、チェックが存在しないことを確認	修正案とともに報告
MEDIUM	チェックが存在する可能性があるが確認できなかった	要検証として報告
LOW	理論上、または他の場所で緩和されている	報告しない

ステップ 1: コードを分類する

レビュー対象を判断し、関連するリファレンスを読み込みます。

コードの種類	読み込むリファレンス
API エンドポイント（*Endpoint を継承）	references/endpoint-patterns.md
シリアライザーまたはフォームフィールド	references/serializer-patterns.md
メールテンプレートまたは HTML レンダリング	references/output-sanitization.md
トークン、OAuth、またはセッション処理	references/token-lifecycle.md
ロールまたは権限のロジック	references/privilege-escalation.md

コードが複数のカテゴリにまたがる場合は、関連するすべてのリファレンスを読み込んでください。

常に読み込む references/enforcement-layers.md — これは Sentry のリクエストライフサイクルにおいてセキュリティチェックが正当に存在し得る場所を文書化したものです。どのレイヤーにおけるチェックも施行としてカウントされます。

ステップ 2: 上位 6 つの脆弱性クラスをチェックする

これらは過去 1 年間の実際のパッチにおける頻度順に並んでいます。

チェック 1: クロス組織オブジェクトアクセス（IDOR） — 過去 1 年間で 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"]) — org スコープなし
• Model.objects.filter(id=request.GET["id"]) — org スコープなし
• リクエストボディ/クエリからの project_id が、Project.objects.filter(id=pid, organization_id=organization.id) を経由せずに直接使用されている
• エンドポイントが OrganizationEndpoint を継承しているが、ハンドラーメソッドが organization パラメータを受け取らない、または使用していない

安全なパターン:

• クエリに organization_id=organization.id が含まれており、organization が convert_args() から取得されている
• 内部で org によってスコープされる self.get_projects() を使用している
• オブジェクトが convert_args() によって解決された URL kwargs を介して取得されている
• スコープされていないクエリがエラーを発生させるだけのガードであり（データを返すことは決してない）、かつ 同じフロー内の下流のクエリが org スコープされており同じエラーを発生させる — 差分となる挙動がなければ情報漏洩もない

チェック 2: 認可チェックの欠如 — 過去 1 年間で 10 件のパッチ

エンドポイントまたはシリアライザーが、ユーザーに権限があることを検証せずに機密性の高い操作を実行しています。

チェック:

• エンドポイントは正しい基底クラスを継承していますか？（OrganizationEndpoint、ProjectEndpoint など）
• permission_classes を宣言していますか？そうでない場合、基底クラスのデフォルトを継承します — それが適切であることを確認してください。
• 他のオブジェクトを参照するシリアライザーのフィールドについて: ユーザーがそれらのオブジェクトにアクセスできることを検証していますか？
• Django ビュー（DRF ではない）の場合: @login_required または同等のものはありますか？

チェック 3: 権限昇格 / ロールの悪用 — 過去1年間に3件のパッチ

ユーザーが、自分のロールで許可されている範囲を超えて、所有権の割り当て、ロールの変更、またはアクセス権限の昇格を行える状態です。

チェック:

• 所有者/担当者フィールド: ActorField（任意のアクターを許可）ではなく、OwnerActorField（メンバーシップを検証）を使用しているか
• ロール変更エンドポイント: リクエスト元ユーザーのロールが対象ロール以上であることを検証しているか
• チーム割り当て: ユーザーが対象チームのメンバーであること（または team:admin を持つこと）を検証しているか

チェック 4: トークン / セッションのセキュリティ — 過去1年間に5件のパッチ

不正なアクセスを可能にするトークンのライフサイクル上の隙間です。

チェック:

• トークン更新: リフレッシュを許可する前に、アプリケーションのアクティブステータスを確認しているか
• 組織レベルのトークン: organization_id が必須で、かつ検証されているか
• メンバーステータス: トークンを発行する前に、メンバーの有効/無効ステータスを確認しているか
• なりすまし: なりすましセッションにレート制限が適用されているか

チェック 5: 出力のサニタイズ（XSS/HTML インジェクション） — 過去1年間に4件のパッチ

メール、Markdown、または HTML 内で、ユーザーが制御できる文字列が安全でない形でレンダリングされています。

チェック:

• メールテンプレートで使用されるユーザーの表示名、チーム名、組織名: サニタイズされているか
• Markdown のレンダリング: カスタム CSS や HTML が通過できるようになっていないか
• テンプレートにおける format_html() と文字列連結の比較
• ユーザー入力に対して mark_safe() が呼び出されていないか

チェック 6: 認証/MFA の隙間 — 過去1年間に3件のパッチ

認証状態の不整合です。

チェック:

• 認証器を削除するとき: リカバリーコードはクリーンアップされるか
• CSRF トークンの扱い: タブ/ウィンドウ間で同期されているか
• セッションの無効化: 認証要素を削除すると、セッションが適切に無効化されるか

チェックで潜在的な検出事項が1つも生成されなかった場合は、停止して検出事項ゼロを報告してください。レポートを埋めるために問題をでっち上げないでください。コードにこれらのパターンに該当する脆弱性がない場合、空の結果が正しい出力です。

ステップ 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 のチェックリストを使用して、そのチェックがすべての層に存在しないことを確認してください。

そのチェックがすべての層に存在しないことを確認できない場合は、検出事項を HIGH ではなく MEDIUM（要検証）としてマークしてください。

トークン発行のためのクロスフロー強制: トークン/資格情報の発行フローでは、発行された資格情報が使用時にブロックされるかどうか（例: determine_access() が関連スコープ内のすべてのエンドポイントでそれを拒否するか）も確認してください。強制の範囲に基づいて分類します。

• 集中的な強制（影響を受けるスコープ内のすべてのエンドポイントが継承する権限クラスでチェックが実行される） → その資格情報は実質的に無効 → LOW（報告しない）
• 散在する強制（一部のエンドポイントまたはシリアライザーだけがチェックし、他はチェックしない可能性がある） → MEDIUM（要検証として報告）

enforcement-layers.md の「クロスフロー強制」を参照してください。

非 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]
  ```

• 前例: [該当する場合は類似の過去の修正、例: 「#104990 PromptsActivity IDOR と類似」]

要検証

[MEDIUM 信頼度の項目と、何を検証すべきかの説明]

未レビュー

[このレビューの範囲外の領域]

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