owasp-security-code-review

OWASP セキュリティコードレビュー

このスキルを使用して、アーキテクチャから開始し、具体的な実行経路をたどる手動のセキュリティレビューを実施します。明確に適合する言語、フレームワーク、CI、クラウド、インフラストラクチャのレビュー用スキルがある場合は、そちらを優先してください。このスキルは、ベースラインの網羅と横断的なレビューのロジックに使用します。

レビューの原則

• 問題を報告する前に脅威モデルを作成します。アクター、資産、信頼境界、権限レベル、攻撃者が制御できる入力を特定してください。
• エントリーポイント、IDに関する判断、権限の変更、機密データの移動を主要な起点として扱います。
• ソースから変換やガードを経て、シンクまたはセキュリティ上の判断に至るまで、問題をエンドツーエンドで確認します。
• 確認済みの脆弱性と、疑わしいパターンや未回答の疑問を区別します。
• 推測に基づく問題の一覧よりも、十分に裏付けられた少数の指摘を優先します。
• レビューした対象、除外した領域、確信度に影響する前提を記録し、網羅状況を明確にします。
• 確認済みの指摘ごとに、レビュー用ワークスペース内に独立した poc_<finding_slug>.py アーティファクトを必ず1つ作成または更新します。

参考資料

• 通常のレビューでは、以下のローカル参考資料を使用してください。ユーザーが出典の確認や最新のガイダンスを求めた場合に限り、OWASPの上流ページを取得してください。
• 入力処理、インジェクション、認証、認可、デシリアライゼーション、XML、暗号実装のパターンをレビューする際は、references/common-vulnerability-patterns.md を参照してください。
• 複数段階の攻撃経路のマッピング、重要なビジネスワークフローのレビュー、脅威モデルから具体的なコードパスへの落とし込みには、references/attack-trees.md を参照してください。
• OWASPのレビューワークフロー、ソースからシンクへの追跡、ベースラインレビューと差分ベースレビューのプロンプトについては、references/owasp-secure-code-review.md を参照してください。
• 入力とインジェクション固有のパターンについては、references/owasp-input-validation.md、references/owasp-sql-injection.md、references/owasp-xss.md、references/owasp-file-upload.md、references/owasp-os-command-injection.md、references/owasp-nosql-security.md を参照してください。
• IDとアクセス制御のパターンについては、references/owasp-authentication.md、references/owasp-session-management.md、references/owasp-authorization.md を参照してください。
• シリアライゼーション、XMLパーサー、暗号化ストレージのパターンについては、references/owasp-deserialization.md、references/owasp-xxe.md、references/owasp-cryptographic-storage.md を参照してください。

レビュープロセス

1. アーキテクチャにセキュリティ上のアンチパターンがないかレビューします。

   • コンポーネント、言語、フレームワーク、ストレージ、外部連携、特権ジョブ、デプロイ境界を一覧化します。
   • 内部ネットワークへの信頼、共有管理者パス、テナントの混在、安全でないプラグインやデシリアライゼーションの対象範囲、動的コード実行、シークレットを扱うサービスなどの信頼に関する前提を特定します。
   • セキュリティ制御が一元化されている箇所と、別の経路から迂回される可能性のある箇所を記録します。

2. エントリーポイントと入力検証を分析します。

   • HTTP/RPCルート、GraphQLリゾルバー、メッセージコンシューマー、Webhook、CLIコマンド、スケジュールされたジョブ、ファイルのインポート、デシリアライザー、設定入力を列挙します。
   • パース、正規化、正規形への変換、スキーマ検証、型検査、サイズ制限、許可リスト、拒否時の動作を追跡します。
   • 別のエンコーディング、重複パラメーター、パスの混同、オブジェクトバインディングの問題、危険なシンクに到達した後に行われる検証を調査します。

3. 認証と認可を検証します。

   • ユーザー、サービス、バックグラウンドジョブの各フローで、アイデンティティがどのように確立、更新、伝播、失効するかを整理します。
   • セッション、トークン、API キー、mTLS、サービスアカウントの検証に関する前提を確認します。
   • 代替ルートや非同期ハンドラーも含め、すべての読み取り、書き込み、エクスポート、状態遷移で、必要なロール、テナント、所有権、オブジェクトレベルのチェックが適用されることを検証します。
   • ミドルウェア、ポリシーエンジン、上流のアイデンティティデータが存在しない、または不正な形式の場合に、フェイルオープンになる動作をテストします。

4. データフローを追跡します。

   • 信頼できないデータが SQL／NoSQL クエリ、テンプレート、ファイルシステムパス、アーカイブ、リダイレクト、送信リクエスト、コマンド実行、ログ、シリアライズ、キャッシュ、クライアントへのレスポンスに到達するまで追跡します。
   • 認証情報、トークン、個人データ、キーなどの機密データが、ストレージ、テレメトリ、エラー、エクスポート、サードパーティとの境界を通過する経路を追跡します。
   • 各経路におけるサニタイザー、エンコーダー、エスケープ処理、パラメーター化、権限境界を記録し、それぞれの制御が送信先に適切かを検証します。

5. ビジネスロジックを分析します。

   • 承認、決済、招待、パスワードリセット、アカウント復旧、クォータ、エンタイトルメント、テナント分離、管理者操作などの重要なワークフローを、状態と不変条件としてモデル化します。
   • リプレイ、競合、順序、古い状態、二重支払い、部分的な失敗、TOCTOU の動作を確認します。
   • 手順を省略する、成果物を再利用する、識別子を変更する、想定外の経路から特権状態遷移を呼び出す方法がないか調べます。

6. 暗号の実装をレビューします。

   • パスワードハッシュ、暗号化、署名、MAC、乱数、鍵導出、鍵の保存、証明書の検証、トークンの構築を特定します。
   • 最新のプリミティブ、安全なパラメーター、ノンス／IV の一意性、該当する場合の定時間比較、鍵の分離、ローテーション、障害時の動作を検証します。
   • 独自暗号、ハードコードされた鍵、弱い乱数、無効化された TLS 検証、署名されていないトークンや一部しか検証されないトークンは、優先度の高いレビュー対象として扱います。

7. エラー処理を検証します。

   • 認証、認可、検証、トランザクションの各境界で、エラー時にフェイルクローズするか確認します。
   • 例外の握りつぶし、フォールバック動作、リトライ、部分コミット、デフォルト値、詳細すぎるレスポンス、スタックトレース、シークレットを含むログをレビューします。
   • セキュリティに関わる障害を、機密情報を漏らさずに検知できることを確認します。

8. 構成とデプロイをレビューします。

   • デバッグモード、CORS、信頼するプロキシ、ホスト検証、Cookie フラグ、セキュリティヘッダー、ログ記録、機能フラグ、シークレットの読み込みに関するデフォルト値と環境変数の解析を確認します。
   • 対象範囲に含まれる場合は、コンテナ／ランタイムの権限、ファイルシステムのパーミッション、ネットワークへの露出、クラウド／IAM のバインド、CI/CD のシークレット、ビルド時の置換、本番環境と開発環境の差異をレビューします。
   • 安全なデプロイを、文書化されていない運用者の対応に依存させる、安全でないデフォルト値を特定します。

9. PoC の成果物を作成します。

   • 確認済みの各指摘について、独立して実行できる poc_<finding_slug>.py ファイルを1つ作成または更新します。
   • 各 PoC は段階的に進められるものにします。前提条件、認証または必要な情報の取得、トリガー、影響の検証、クリーンアップのガイダンスを番号付きで表示または実装します。
   • リクエストを送信する前に、攻撃者の立場、必要な権限、認証情報または証明書、環境依存条件、未検証の前提条件を明記します。
   • デフォルトではドライランまたは無害なマーカーを使用し、状態を変更する検証には明示的なフラグを必須とします。
   • 安全に実行できる手段がない指摘についても、指摘ごとの PoC のひな形を作成し、不足している前提条件または安全でない手順を説明します。
   • 各スクリプトの構文チェックとドライランを行い、実際の環境で実行した手順と実行しなかった手順を記録します。

検出基準

次の内容を報告できる場合に限り、検出事項として報告してください。

• 影響を受けるコードパス（ファイル名と行番号を含む）
• 攻撃者が制御できる入力、または信頼に関する前提の違反
• 欠落、回避、または誤った制御
• 到達可能な影響と必要な前提条件
• 具体的な修正方針
• 焦点を絞った回帰テストまたは検証手順

完全な経路が特定できない懸念や、実行時のコンテキストが不明なために生じる懸念は、確認済みの脆弱性ではなく、未解決の質問またはカバレッジの不足として示してください。

出力

重要度の高い順に検出事項を記載してください。各検出事項には、Severity、Location、Issue、Exploit Path、Impact、Remediation、Test、PoC Requirementsを含めてください。

確認済みの各検出事項について、対応するpoc_<finding_slug>.py成果物をレポート内で参照し、必要最小限の攻撃者の立場、必要な権限または認証情報、環境条件、安全なデフォルトの動作、実行例を記載してください。

検出事項の後に、Open Questions / AssumptionsとCoverageを記載してください。確認済みの検出事項がない場合は、その旨を明記したうえで、レビューした対象範囲、未解決のリスク、テストの不足点も記載してください。