analyzing-code-security

セキュリティレビューのワークフロー

手動でセキュリティコードレビューを行う際は、以下の手順に従ってください。

1. 攻撃対象領域を特定します。 エントリーポイントを特定します。API エンドポイント、メッセージハンドラー、ファイルパーサー、ユーザー向けフォームなどが該当します。ルート定義とコントローラーの登録を読み、全体像を把握します。
2. ソースからシンクまでのデータフローを追跡します。 信頼できない入力（HTTP パラメーター、ヘッダー、リクエストボディ、ファイルアップロード、外部 API のレスポンス）が、すべての変換処理を経て、危険な操作（データベースクエリ、コマンド実行、HTML レンダリング、ファイルシステムへのアクセス）に至るまでを追跡します。
3. 信頼境界を越える箇所を確認します。 データが信頼境界（クライアント→サーバー、サービス→サービス、ユーザー入力→データベース）を越えるすべての箇所で、検証、認証、認可が確実に行われていることを確認します。
4. フレームワークのチェックリストを適用します。 OWASP Web／API／Mobile Top 10 と CWE Top 25 については、references/framework-checklists.md を参照してください。該当する各カテゴリを、レビュー対象のコードに照らして確認します。
5. 攻撃者の視点で考えます。 仮説（例：「SSO を回避できる」「他のユーザーの保管庫にアクセスできる」）を立て、悪用可能にする条件を逆方向にたどって特定します。
6. 検出事項を CWE ID に対応付けます。 すべての検出事項に、具体的な CWE 識別子、コードの位置、悪用可能にするデータフローを含める必要があります。
7. 実際の悪用可能性に基づいて分類します。 実際に悪用可能な脆弱性と理論上のリスクを区別します。それに応じて優先順位を付けつつ、両方を記録します。

主な脆弱性カテゴリ

Bitwarden のスタック全体で、特によく見られるカテゴリは次のとおりです。

• インジェクション（CWE-89、CWE-78、CWE-77）— サニタイズされていない入力が、SQL クエリ、OS コマンド、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 の正しいコード例と誤ったコード例