fix-code-vulnerability

コードの脆弱性を修正する

概要

このスキルでは、コードベースのセキュリティ脆弱性を特定、分析、修正するための体系的なアプローチを紹介します。一般的な脆弱性の種類（インジェクション攻撃、入力検証の問題など）を取り上げ、修正が完全かつ正確であることを確認するための検証方法を提供します。

ワークフロー

フェーズ 1：初期調査

まず、脆弱性の範囲と性質を把握します。

1. 最初に既存のテストを実行する - テストスイートを実行し、セキュリティ関連のテストに失敗がないか確認します。失敗したテストから、修正が必要な脆弱性や期待される動作が直接わかることがよくあります。

2. 失敗したテストをすぐに読む - セキュリティテストが失敗した場合は、コードベース全体を調べる前にまずテストを読みます。テストから、次の内容がわかります。

   • 脆弱性の正確な種類（CWE 番号、攻撃ベクトル）
   • 期待される防御動作
   • ブロックすべき具体的な入力
   • テスト対象の API または関数

3. 脆弱性の種類を特定する - 脆弱性を分類します。

   • CWE-89：SQL インジェクション
   • CWE-78：OS コマンドインジェクション
   • CWE-79：クロスサイトスクリプティング（XSS）
   • CWE-93：CRLF インジェクション（HTTP レスポンス分割）
   • CWE-22：パストラバーサル
   • CWE-94：コードインジェクション
   • CWE-611：XML 外部エンティティ（XXE）

フェーズ 2：コード分析

脆弱なコードパスをたどります。

1. データフローを追跡する - ユーザー入力から脆弱な処理までを追跡します。

   • エントリーポイント（API エンドポイント、フォームハンドラー、ファイルリーダー）
   • データ変換関数
   • 出力箇所（データベースクエリ、ファイル操作、HTTP レスポンス）

2. 修正箇所を特定する - 複数の呼び出し元ではなく、共通のヘルパー関数で修正することを優先します。

   • 脆弱なデータを処理するユーティリティ関数を探します
   • 共通ヘルパーを修正すれば、すべての呼び出し元に自動的に対処できます
   • エッジケースを見落とすおそれがある、個別に分散した修正は避けます

3. まとまった範囲のコードを読む - 関連する関数を分析するときは、細かく何度も読み込むのではなく、まとめて読みます。これにより、コードの流れを理解するための文脈が把握しやすくなります。

フェーズ 3：修正の実装

適切な防御策を適用します。

1. 入力検証 - インジェクション脆弱性の場合：

   • 危険な文字（CRLF の場合は \n、\r、\0 など）を検証します
   • 可能な場合は許可リストを使用します（許可するものと許可しないものを定義します）
   • 問題を特定できる、明確なエラーメッセージを表示します

2. 出力エンコード - XSS などの場合：

   • コンテキスト（HTML、URL、JavaScript）に適した出力エンコードを行います
   • フレームワークが提供するエンコード関数を使用します

3. パラメーター化 - SQL インジェクション／コマンドインジェクションの場合：

   • パラメーター化クエリまたはプリペアドステートメントを使用します
   • ユーザー入力との文字列連結は避けます

4. エラー処理 - 修正が次の条件を満たしていることを確認します。

   • 適切な例外を、説明的なメッセージとともに発生させる
   • エラーメッセージから機密情報が漏れない
   • 安全側に失敗する（デフォルトで拒否する）

フェーズ 4：検証

修正が完了していることを確認します。

1. テストスイート全体を実行する - 次のすべてのテストが成功する必要があります。

   • 最初に失敗したセキュリティテスト
   • 既存の機能テスト（リグレッションがないことを確認します）

2. エッジケースが網羅されていることを確認する - 修正が次のケースに対応しているか確認します。

   • 攻撃のあらゆるバリエーション（\n だけでなく、すべての制御文字など）
   • 直接的および間接的な攻撃経路
   • 脆弱性を引き起こす可能性のあるすべてのメソッド

3. 脆弱性レポートを作成する - 次の内容を記録します。

   • 脆弱性の種類と CWE 識別子
   • 影響を受けるコードの箇所
   • 修正内容とその理由
   • テストで網羅されていることの確認

よくある落とし穴

避けるべき間違い

1. 文字の網羅性が不十分 - 危険な文字をブロックする場合は、すべてのバリエーションを対象にしてください（例：CRLF の場合、一方だけでなく \r と \n の両方を対象にします）。

2. 誤ったレベルで修正する - 集中管理された修正方法がある場合は、個々の呼び出し箇所にパッチを適用しないでください。共通のヘルパー関数を見つけてください。

3. 間接的な経路を見落とす - 関数は複数のコード経路から呼び出されることがあります。修正がすべてのエントリーポイントをカバーしていることを確認してください。

4. テストの検証を省略する - 修正を適用したら、必ずテストを実行してください。目視での確認だけでは不十分です。

5. 範囲が広すぎる修正 - 正当な機能を壊さないでください。パターンをブロックする前に、有効な入力がどのようなものかを把握してください。

検討すべき攻撃シナリオ

脆弱性を修正する際は、攻撃の仕組みを理解してください。

• CRLF インジェクション（CWE-93）：攻撃者が \r\n を注入して HTTP ヘッダーを分割し、レスポンス分割攻撃を可能にします
• SQL インジェクション（CWE-89）：攻撃者が文字列コンテキストを脱出し、任意の SQL を実行します
• コマンドインジェクション（CWE-78）：攻撃者がシェルのメタ文字を使ってシステムコマンドを実行します
• パストラバーサル（CWE-22）：攻撃者が ../ の並びを使って、意図されたディレクトリの外にあるファイルへアクセスします

プロセス効率化のヒント

1. テストから始める - まずテストを実行すれば、どのセキュリティチェックが失敗しているか、どのような動作が期待されているかがすぐに分かります。

2. コードを読む前にテストを読む - セキュリティテストには、コードベースを検索するよりも明確に、脆弱性と期待される修正が記述されています。

3. 集中管理された関数を修正する - 共有ヘルパー関数を特定して修正し、最小限の変更ですべてのコード経路をカバーします。

4. 一度で包括的に検証する - リグレッションを検出するため、個別のテストではなくテストスイート全体を実行してください。

5. 脆弱性を文書化する - 脆弱性の種類、適用した修正、実施した検証を説明するレポートを作成してください。