WEB APPLICATION SECURITY
WAFの誤検知とは？
フォールスポジティブ・検知漏れを体系的に理解する
公開日：2026-10-10
ある学習サービスの数式フォームに「2 < 5」と入力すると、なぜか「アクセスがブロックされました」と表示された。実は、攻撃ではない入力に含まれた「<」という文字をWAFが危険と判断したのかもしれません。正常な操作を攻撃と誤判定する「フォールスポジティブ」を、WAFとWebアプリの仕組みから理解しましょう。
HTTPとWAFの位置関係 → SQLインジェクション・XSS → TP/FP/FN/TN → 検知率・適合率 → ルール運用と誤検知調査 → 体験ラボ。応用情報技術者試験で必要な基礎用語も整理します。
1. まずWAFとは？ Webアプリの前でHTTP通信を検査する
WAF = Web Application Firewall。「Web Application」はWebアプリケーション、「Firewall」は通信を検査・制御する防御の仕組みです。一般的なネットワークFWが主にIPアドレス・ポートなどを扱うのに対し、WAFはURL・パラメータ・ヘッダーなどのHTTPリクエストの中身に注目します。
- ブラウザが入力したフォームのデータをHTTPリクエストとして送る。
- WAFが設定ルールや検知スコアにより評価する。
- 許可されればアプリに転送される。遮断時は通常アプリまで届かない。
| 用語 | 意味・役割 | 身近な例 |
|---|---|---|
| ネットワークFW | 通信先IP・ポート等のルールによる制御 | 社内ネットワークからの不要な接続を制限 |
| WAF | HTTP(S)の要求を検査しWebアプリへの攻撃を減らす | 数式フォームやECサイトのログイン・検索を保護 |
| IDS | 不審な通信や挙動を検知し通知 | ネットワークで攻撃兆候を発見 |
| IPS | 検知した不審通信を遮断する | 侵入パターンを検出して通信を止める |
| CDN | 静的配信やキャッシュなどで配信を支援 | 画像やページを近くの拠点から配信 |
現実にはCDNやリバースプロキシとWAFが同じサービス内で提供されることもあります。たとえば Cloudflare WAF やAWS WAFはWebサイトの前段で通信を評価する製品例です。設置形態は提供事業者・構成により異なります。
2. 「陽性」は検査が攻撃と判断したこと
英語の Positive はここでは「検査で攻撃ありと判定」、Negative は「攻撃なしと判定」です。「実際に攻撃かどうか」と「検査がどう判定したか」は別の軸です。
| 実態 ＼ WAFの判定 | 攻撃と判定（陽性・遮断） | 正常と判定（陰性・許可） |
|---|---|---|
| 実際に攻撃 | TP / True Positive 攻撃を正しく検知 | FN / False Negative 攻撃を見逃す |
| 実際は正常 | FP / False Positive 正常なのに誤遮断 | TN / True Negative 正常通信を正しく許可 |
| 用語 | 意味・役割 | 身近な例 |
|---|---|---|
| TP（真陽性） | 攻撃を攻撃と判定 | 不正な入力を検知し遮断 |
| FP（偽陽性） | 正常なのに攻撃と判定 | 数式の「<」で正常な投稿が遮断 |
| FN（偽陰性） | 攻撃なのに正常と判定 | 検査対象外のフィールドの攻撃を見逃す |
| TN（真陰性） | 正常なものを正常と判定 | 通常の検索やログインが成功 |
3. なぜ「<」1文字で正常な操作がブロックされる？
「<」はHTMLタグにも使われますが、算数の「小なり」記号でもあります。単純に文字の有無だけで判断すると、入力の意味を無視してしまいます。
# HTTPリクエストの説明用イメージ POST /math/check HTTP/1.1 Host: learning.example Content-Type: application/x-www-form-urlencoded expression=2%20%3C%205 # URLエンコード後の「%3C」は「<」を表す
- 利用者は正当な数式を入力する。
- 単純な文字列ルールが「<」を危険と判断して遮断する。
- 実態は正常・判定は攻撃なので、False Positive（FP）になる。
これに対し、実際のXSS（クロスサイトスクリプティング）では、Webアプリの出力方法の不備などを利用して、意図しないスクリプト実行を引き起こそうとします。タグらしい文字があることと、実際にXSSが成立することは同じではありません。
4. 見逃し（FN）はどう発生する？
攻撃がWAFに届いても、対象のフィールドを検査していない・ルールにない・HTTPの解釈が後段のWebアプリと異なるなどの理由で検知できないことがあります。
- 攻撃者がアプリ固有の入力フィールドを悪用する。
- WAFの検査対象や解釈が不足しており通過させる。
- 実態は攻撃・判定は正常なのでFalse Negative（FN）になる。
分割されたリクエストなどを、WAFとバックエンドが異なる規則で解釈する場合も危険です。HTTPリクエストスマグリングなどの問題では、フロントエンドとバックエンドの解釈差が攻撃につながることがあります。ただし、すべての分割通信が即座に同じ脆弱性を意味するわけではありません。
5. 身近な場面から4分類を覚える
| 用語 | 意味・役割 | 身近な例 |
|---|---|---|
| 正常なブログ投稿がHTMLの例示で遮断 | FP：正常 → 遮断 | 技術ブログでコード例を書けない |
| 危険な入力をWAFが検出し遮断 | TP：攻撃 → 遮断 | 想定した防御が機能 |
| 危険な通信をWAFが見逃して通過 | FN：攻撃 → 許可 | 本来止めたい通信が到達 |
| 普通の買い物操作が問題なく通過 | TN：正常 → 許可 | ECサイトの決済前フォームを利用できる |
| アンチウイルスが安全なツールを隔離 | FPの別分野の例 | セキュリティソフトの過剰検知 |
| 迷惑メールが受信トレイに入る | FNの別分野の例 | 迷惑メール判定の検知漏れ |
FPとFNはWAF限定の用語ではありません。迷惑メール、マルウェア対策、IDS/IPS、AIによる不正検知などでも同じ4分類を使います。
6. 数字でも理解する：適合率・再現率・偽陽性率
応用情報などで判定結果を定量的に評価するときは、混同行列から指標を計算します。単に「検知率が高い」といっても、正常なリクエストを大量に誤遮断している可能性があります。
| 用語 | 意味・役割 | 身近な例 |
|---|---|---|
| 適合率 Precision | TP / (TP + FP) | 遮断したものの何割が本当の攻撃か |
| 再現率 Recall / TPR | TP / (TP + FN) | 実際の攻撃を何割見つけたか |
| 偽陽性率 FPR | FP / (FP + TN) | 正常な入力の何割を誤遮断したか |
| 正解率 Accuracy | (TP + TN) / 全件 | 全体の判定が正しかった割合 |
| F1スコア | 2 × Precision × Recall / (Precision + Recall) | 適合率と再現率を調和平均で見る |
7. 操作ラボ：ルールを変えるとFPとFNはどうなる？
「数式」「HTML教材」「商品検索」「攻撃を想定した入力」を選び、単純な文字列検知と文脈を考慮した模式的な検知を切り替えます。下部では架空の混同行列の数値も調整できます。
INTERACTIVE LAB
WAF判定・誤検知シミュレーター
入力の実態（正常／攻撃）とWAFの判定（許可／遮断）を分けて考えます。すべて画面内で完結する模式的な判定で、実WAFの再現ではありません。
検査対象の入力例（文字列表示のみ）
2 < 5実態
正常WAFの判定
遮断4分類
FP：誤検知数式で「小なり」を表しているだけの正常な入力
仮想の検知しきい値と混同行列
正常950件・攻撃50件を想定した説明専用の架空データです。厳しい設定ほど攻撃を拾いやすい一方、正常リクエストも誤って遮断しやすい例を示します。
| 実態 ＼ 判定 | 遮断（陽性） | 許可（陰性） |
|---|---|---|
| 攻撃 | TP 35正しい検知 | FN 15見逃し |
| 正常 | FP 57誤検知 | TN 893正しい許可 |
適合率 Precision = TP / (TP + FP)
38.0%遮断したもののうち、本当の攻撃の割合
再現率 Recall = TP / (TP + FN)
70.0%本当の攻撃のうち、検知できた割合
注意：検知を強めると必ず同じ比率でFP・TPが増えるとは限りません。実際の検出性能はルール、通信内容、アプリ仕様、攻撃の種類に依存します。
8. 実務ではどう直す？ Cloudflare WAFを例に
Cloudflareの公式ドキュメントでは、正常な要求が管理ルールにブロックされた場合、セキュリティイベントで該当ルールを調べ、条件を限定した例外や個別ルールの調整を行うことが説明されています。WAF全体を無効にする前に、どのリクエストとルールが衝突しているかを特定します。
- 利用者からURL、時刻、操作内容などを確認し、機密情報の取り扱いに注意してログを調べる。
- 正常な業務操作かどうかと、マッチしたルールID・リクエストの条件を確認する。
- 特定パス・パラメータ・ルールに限定した例外などを検討し、テストしてから反映する。
- 変更後は攻撃検知の低下や新たな誤検知が起きていないか継続監視する。
| 用語 | 意味・役割 | 身近な例 |
|---|---|---|
| ルール除外・例外 | 必要な経路や条件だけ特定ルールをスキップ | 教材投稿パスに限って特定ルールを調整 |
| 検知モード・ログ観測 | 遮断前に影響を調べる運用 | 新ルールの導入時に試験観測 |
| 異常スコア方式 | 複数ルールのスコアと閾値で評価 | 単独の弱い兆候だけで即遮断しない設計 |
| 段階的導入 | 影響を測りながら対象を広げる | 検証環境から本番の一部へ |
| 変更管理 | 例外の根拠・期限・担当者を記録 | 永続的な無条件除外を防ぐ |
9. 体系的なまとめ：何を判断すればよいか
試験でも実務でも、まず「現実には攻撃だったか／正常だったか」、次に「WAFは遮断したか／通したか」を分けます。この2軸だけでTP・FP・FN・TNが決まります。さらに、予防は入力値検証・出力エスケープ・パラメータ化クエリ、補完的防御はWAF、運用改善はログ分析とルール調整と整理すると、知識がつながります。
10. 参考資料
- WAF managed rules troubleshooting（Cloudflare）
- Create WAF exceptions（Cloudflare）
- OWASP Core Rule Set（OWASP）
- Web Application Firewall（OWASP）