「WAFを入れていれば安心」という幻想を破壊する：インジェクション攻撃の最前線
「WAF（Web Application Firewall）を導入しました。これでSQLインジェクション対策は万全ですよね？」
現場で若手エンジニアからこの質問を受けるたび、私は少しだけ苦い顔をする。断言しよう。WAFは「盾」だが、決して「無敵の鎧」ではない。WAFはあくまで、アプリ側の脆弱性を補完する最後の防衛線だ。WAFに依存しきったシステムは、少しのエンコーディングの工夫やロジックの隙間で、いとも簡単に突破される。
今日は、攻撃者がWAFをどう「読み」、どう「回避」しようとするのか、そして我々が実装レベルでどう守り抜くべきか、泥臭い実務の視点から解説する。
—
1. WAFの検知メカニズムと「越えられる」理由
WAFの検知には主に2つの手法がある。
1. シグネチャベース: UNION SELECT や OR 1=1 といった、既知の攻撃パターンをブラックリスト形式でマッチングする。
2. 振る舞い検知（アノマリ検知）: 通常のトラフィックから逸脱したリクエスト（異常な長さ、変な文字コードの羅列など）を弾く。
攻撃者はこれに対し、「エンコーディングの多重化」や「SQLの構文の揺らぎ」を使ってシグネチャをすり抜ける。例えば、' OR 1=1 が弾かれるなら、' O//R 1=1 とコメントを挟んだり、16進数でエンコードしたりして、アプリ側でデコードされた瞬間に実行させる。
WAFはあくまで「入口の門番」だ。門番が寝ている間に、アプリ内部に毒を混ぜるような脆弱なコードがあれば、そこでおしまいだ。
—
2. インジェクションを無効化する：セキュア実装の鉄則
WAFのルール設定に腐心する前に、まず「アプリ側で攻撃を成立させない」ことが最優先だ。SQLインジェクションであれば、プリペアドステートメント（静的プレースホルダ）を使うことは宗教上の義務だと心得てほしい。
実装サンプル：PHP (PDOを使用)
文字列結合でクエリを作るのは、自ら「ハックしてください」と看板を掲げるようなものだ。
// NG: 脆弱な実装
// $sql = “SELECT FROM users WHERE id = ” . $_GET[‘id’];
// OK: プリペアドステートメントの使用
$stmt = $pdo->prepare(‘SELECT FROM users WHERE id = :id’);
// 変数を直接結合せず、プレースホルダ経由で安全にバインドする
$stmt->execute([‘id’ => $_GET[‘id’]]);
$user = $stmt->fetch();
これだけで、どんなに悪意のある文字列を投げ込まれても、データベースはそれを「ただのデータ」として扱い、命令として解釈することはない。
—
3. Nginx + ModSecurity を使った「現実的な」防御設定
アプリ側の修正と並行して、WAF（ここではオープンソースのWAFであるModSecurity）で多層防御を敷く。重要なのは、「何でもかんでもブロックして正常なトラフィックを止める」ことではなく、「明らかに攻撃とわかるリクエストを最小単位で落とす」ことだ。
以下は、modsecurity.conf における基本ルール設定のイメージだ。
ModSecurityの基本設定例
SecRuleEngine On
SQLインジェクションのシグネチャを検知するルール例
攻撃の兆候（UNIONやSELECT等）を含むリクエストを拒否
SecRule ARGS “@pm UNION SELECT INSERT DELETE UPDATE DROP” \
“id:10001,phase:2,deny,status:403,msg:’SQLi detected'”
OSコマンドインジェクション対策（; や | や & を監視）
SecRule ARGS “@rx [;&|]” \
“id:10002,phase:2,deny,status:403,msg:’OS Command injection attempt'”
運用上のポイント:
いきなり deny（遮断）に設定すると、正規のユーザーがフォームに入力した「珍しい文字」でエラーになる可能性がある。まずは log モードで運用し、誤検知（False Positive）がゼロであることを確認してから deny に切り替えるのが、インシデントハンドラーの常套手段だ。
—
4. 最後に：エンジニアが持つべき「マインドセット」
WAFを導入する際は、以下の3点を意識してほしい。
- ログを愛せ: WAFがブロックしたログを毎日眺めろ。そこに、今のあなたのシステムが狙われている「攻撃の傾向」がすべて記されている。
- 多層防御を疑え: 「WAFがあるから入力チェックは甘くていい」という甘えが出た瞬間が、そのシステムの寿命だ。
- PoC（概念実証）を自ら行え: 自分で作ったアプリに対し、ツールや手動でインジェクションを試みろ。自分で突破できないセキュリティは、信頼に値しない。
セキュリティは、ツールを導入して終わりではない。それは、エンジニアがコードを書くその指先から始まる、終わりのないチェスゲームのようなものだ。
君たちが書くコードが、次の「突破困難な要塞」になることを期待している。もし突破されたとしても、それは君を強くするための糧にすぎない。また戦えばいい。応援しているぞ。
コメント