SQLインジェクションの対策と緩和#

1. 脆弱性の概要 / 影響#

SQLインジェクション（SQLi）とは、Webアプリケーションがユーザー入力をSQLクエリに安全に組み込まず、攻撃者が任意のSQL構文を注入できる脆弱性です。OWASPにおいても代表的なWeb脆弱性として位置づけられており、脆弱性が悪用された場合は以下のような深刻なインシデントに発展する可能性があります。

  • 情報漏えい: 顧客情報や機密データの漏えい。
  • データ改ざん・破壊: データの書き換えやテーブルの削除。
  • 認証回避: 管理者権限での不正ログイン。

2. 根本的な対策#

SQLインジェクションの根本的な対策は、プリペアードステートメント（静的プレースホルダ） の利用です。ユーザー入力をSQLの構造部分から切り離すことで、攻撃者によるSQL構文の注入を原理的に防ぐことができます。

ただし、長期間運用されているレガシーシステムでは、以下の理由により根本対策の適用が困難なケースがあります。

  • 複雑な動的SQL文: 数百〜数千行に及ぶSQLテンプレートが文字列連結で構築されている。
  • フレームワークの制約: プリペアードステートメントをサポートしない古いライブラリや独自フレームワークを使用している。
  • リソース制約: 大規模な改修に伴うリグレッションテストの工数が確保できない。

3. 緩和策#

根本対策が困難な場合、単一の防御策に依存することはリスクがあります。複数の緩和策を設けた多層防御を構築し、攻撃の成立難易度を高めることが求められます。 これらの緩和策は脆弱性を根本的に排除するものではありません。長期的にはシステムの刷新やコードベースの安全な書き換えが必須です。

3.1 アプリケーション層#

コードレベルでの修正が限定的に可能な場合に実施すべき対策です。

3.1.1 厳格な入力バリデーション#

SQL構文として解釈されうる文字の混入を未然に防ぎます。

  • 型チェックの徹底: 例えば、数値として扱われるべきパラメータ（ID、フラグ等）は、必ず数値型にキャストしてからSQLに埋め込みます。
  • ホワイトリスト検証: ソート順（ASC/DESC）やテーブル名など、プレースホルダが使えない識別子は、許可された文字列リストと照合します。

3.1.2 独自エスケープ処理#

OWASPガイドラインでは推奨されていませんが、プリペアードステートメントが利用できない場合の最終手段として使用します。

  • DBエンジン固有の仕様への準拠: PHPのビルトイン関数である mysql_real_escape_string 相当の処理など、使用するDBエンジンの仕様に完全に準拠したエスケープ関数を使用します。※なお、mysql_real_escape_stringのサポートはPHP5までで、現在使用されている 7.x系では削除されています。
  • メタ文字の無害化: '（シングルクォート）、"（ダブルクォート）、\（バックスラッシュ）、;（セミコロン）などを確実にエスケープします。

3.2 データベース層#

3.2.1 データベースファイアウォール#

アプリケーションから送信されるSQLクエリを監視し、不正なパターンを遮断します。

  • クエリホワイトリスト:
    • 学習フェーズ: 正常な運用時の全SQLパターンを学習し、ホワイトリストを作成します。
    • 運用フェーズ: リストに含まれない未知のSQL（攻撃によって構造が変化したSQL）をブロックします。
  • 製品例: MySQL Enterprise Firewall、Oracle Database Firewall、各種商用DBセキュリティ製品。

3.2.2 最小権限の原則#

万が一インジェクションが成功した場合の被害範囲を最小限に抑えます。

  • ユーザー分離: アプリケーションからの接続ユーザーを用途別に分割します。

    ユーザー付与する権限
    App_ReadSELECT のみ
    App_WriteINSERT、UPDATE のみ

  • 危険な権限の剥奪: DROP、ALTER、GRANT などの管理権限、およびファイル操作やOSコマンド実行に関わるストアドプロシージャの実行権限を剥奪します。

3.3 インフラ・ネットワーク層#

3.3.1 Web Application Firewall (WAF)#

HTTPリクエストレベルで一般的なSQLインジェクション攻撃パターンを検知・遮断します。既知の攻撃ツールやスキャナからの防御に有効です。

3.3.2 アウトバウンド通信の制限#

データベースサーバーからインターネットへの直接接続を遮断します。これにより、攻撃者がデータを外部サーバーへ送信する「Out-of-Band SQLi」等の手法を無効化できます。

3.4 推奨優先順位#

緩和策の優先順位の目安として、以下を参考にしてください。

  1. 即時対応: DBユーザーの権限見直し（最小権限化）、入力値バリデーションの強化。
  2. 短期対応: WAFおよびDB Firewallの導入検討と検証。
  3. 中長期対応: システムのフルリプレース、またはプリペアードステートメントに対応したモダンなフレームワークへの移行。

4. 緩和策実施後も残存するリスク#

緩和策を講じたとしても、以下のリスクは残存します。各対策の限界を認識したうえで、リスク受容の判断を行う必要があります。

対策区分実装策残存リスク
アプリケーション層独自エスケープ実装ミスや文字コード処理の不備によるバイパス（例: Shift_JISにおける 0x5C 問題）
データベース層DB Firewall学習漏れによる正常クエリのブロック（可用性リスク）、正常な構造に見える論理的な攻撃
インフラ・ネットワーク層WAFエンコーディングや難読化による検知回避、ゼロデイ攻撃

これらの緩和策はリスク低減策として位置づけ、根本対策（プリペアードステートメントへの移行）を継続的に検討することが重要です。緩和策を導入した場合でも、それを恒久対策とみなすのではなく、システム刷新の計画を維持し続けることが求められます。

5. 参考文献#