WAFの「運用」をハックせよ：シグネチャ頼みで終わらせない誤検知との泥臭い闘い
現場でインシデント対応をしていると、「WAFを入れたからもう安心だ」という甘い言葉を耳にすることがある。だが、断言しよう。WAFは銀の弾丸ではない。むしろ、適切にチューニングされていないWAFは、攻撃者に「どのパターンなら検知を回避できるか」というヒントを与え、正規ユーザーを締め出すだけの「高価な置物」に成り下がる。
今日は、シグネチャベースの防御がいかに脆く、そしてどうやって実務レベルの「要塞」に昇華させるか、その泥臭い現場の戦術を共有する。
—
1. 攻撃者が狙う「シグネチャの死角」
SQLインジェクション（SQLi）やクロスサイトスクリプティング（XSS）をWAFで止める際、多くのエンジニアはベンダー提供のルールセットを「全適用」して満足する。だが、攻撃者はその裏をかく。
例えば、単純な UNION SELECT は即座にブロックされるが、以下のような「WAFが正規のSQLクエリと誤認しやすい」ペイロードはどうか。
-- スペースをコメントアウトや改行に置き換える手法
1/**/UNION/**/SELECT/**/null,username,password/**/FROM/**/usersWAFのシグネチャは、特定のキーワード（SELECT, UNION）を検知するが、/**/ のような構文を「コメント」として適切に解釈できない、あるいはパーサーの制限で無視してしまうケースがある。ここが最大の盲点だ。
—
2. 誤検知（False Positive）との終わりなき闘い
WAFを「Blockモード」にした途端、管理画面のログが真っ赤に染まることは日常茶飯事だ。特に、CMSの管理画面や複雑なJSONを投げるAPIでは、正規のデータが SELECT や <script> という文字列を含むだけで遮断される。
ここで「とりあえず除外ルールに追加」を繰り返すと、セキュリティ強度はゼロに近づく。重要なのは、「何が正規で、何が異常か」をコンテキストで絞り込むことだ。
推奨される例外設定の考え方（Nginx/ModSecurityの例）
全体を一律に許可するのではなく、特定のパスやリクエストパラメータに限定して例外を設定する。これが鉄則だ。
# ModSecurityのルール例：特定のパスのみ、特定のルールIDを無効化する
# 運用環境では「闇雲に全体を許可」は絶対に避けること
SecRule REQUEST_URI "@beginsWith /api/v1/user/profile/update" \
"id:1001,phase:1,nolog,pass,ctl:ruleRemoveById=942100"
# ※ 942100はSQLi検知ルール。APIの仕様上、どうしても必要な場合のみピンポイントで外す—
3. アプリケーション層での「守り」を忘れるな
WAFは「外壁」に過ぎない。中身（アプリケーション）がスカスカなら意味がない。特にPHPやPythonで開発する際は、ライブラリやORMの機能で「構造化」を強制することが、WAFの負荷を下げる最短ルートだ。
SQLiを防ぐためのセキュアな実装（PHP/PDO）
文字列連結でSQLを作るのは、今すぐやめよう。プリペアドステートメントを使えば、WAFが検知する前にSQLエンジン側で安全に処理される。
<?php
// 悪い例： $sql = "SELECT * FROM users WHERE id = " . $_GET['id'];
// 良い例： プリペアドステートメントを使用する
$pdo = new PDO('mysql:host=localhost;dbname=test', 'user', 'pass');
$stmt = $pdo->prepare('SELECT username FROM users WHERE id = :id');
// バインドすることで、データがSQLコマンドとして解釈されるリスクを排除する
$stmt->execute(['id' => $_GET['id']]);
$user = $stmt->fetch();
?>XSSを防ぐためのセキュアな出力（JavaScript）
DOM操作で innerHTML を使うのは、XSSの招待状を送るようなものだ。textContent を使えば、ブラウザ側で自動的にエスケープされる。
// 悪い例： element.innerHTML = userInput;
// 良い例： テキストとして挿入することでスクリプト実行を無効化する
const userInput = "<script>alert('XSS')</script>";
const element = document.getElementById('user-comment');
// textContentなら、タグはただの文字列として表示されるだけ
element.textContent = userInput;—
4. チーフエンジニアからの提言：運用の要諦
セキュリティ対策のゴールは「完璧な防御」ではなく、「攻撃コストを最大化し、検知率を向上させること」にある。
1. ログを疑え: WAFの検知ログを毎日確認しろ。特に「異常な通信」が集中しているIPアドレスは、攻撃の予兆か、あるいは自社アプリの仕様が非効率であることの証左だ。
2. DevOpsに組み込め: WAFのルール変更を本番環境で直接いじるな。CI/CDパイプラインに「脆弱性スキャン」と「WAFルールテスト」を統合し、デプロイ前に遮断テストを行う環境を整えろ。
3. シグネチャを過信するな: 最後に守るのは、あなたが書いたコードの堅牢性だ。WAFはあくまで「保険」。基本は、バリデーションとパラメータ化にある。
セキュリティは、一度構築して終わりではない。攻撃者の手法も、開発するアプリの構成も日々進化する。「昨日までの正解が、今日の脆弱性になる」。この緊張感を持ち続けられる者だけが、システムを真に守ることができる。
現場からは以上だ。次は、君のコードで安全な明日を実装してくれ。
コメント