WAF・シグネチャ・許可／拒否リスト・誤検知

業務用の検索欄にSQLの構文に見える文章が入力され、WAFが遮断しました。これは攻撃を防いだ記録でしょうか、それとも正規利用者の作業を止めた誤検知でしょうか。架空のhttps://orders.exampleを例に、WAFの検査点、シグネチャ、許可・拒否、誤検知と見逃し、運用の調整方法を追います。

科目B（午後）では『WAFで防ぐ』だけで答えず、どの要求がWAFを通り、どのフィールドを検査し、どのルール・しきい値で処置したかを読みます。攻撃の成立や情報流出はWAFの一致ログだけでは断定できません。以下のドメイン、IP、時刻、ルールID、ログは教材用の架空例です。

1. WAFの位置と観測範囲

orders.exampleの公開入口でTLSを終端し、HTTPリクエストをWAFが検査してからアプリへ渡す構成とします。アプリの内部IPは10.0.2.30です。管理APIは別ホストadmin.orders.exampleで、同じWAFの対象かどうかを明示して管理します。

図の通常経路ではWAFはHTTPを見られます。しかしオリジンへ別経路で直通できる場合、直通分の要求をWAFは観測しません。オリジンのFWでWAFの送信元だけを許可し、別ドメイン・IPv6・管理用経路も棚卸しします。WAFがない経路をログ欠落だけから断定せず、オリジン接続元を確認します。

2. シグネチャとしきい値は何を判定するか

POST /api/orders/searchのquery欄には、顧客が自由記述の注文メモを入れます。W-941はSQLに似た文字列を検出し、W-920はHTTP形式の異常を検出する架空ルールです。WAFは各一致を記録し、この例では合計スコアが5以上なら遮断します。

仮のWAF方針:
  path=/api/orders/search
  W-941: SQL風文字列の一致 -> +5
  W-920: 異常なHTTP形式 -> +3
  score >= 5 -> block
  score < 5  -> log and pass

正規のメモ例:
  "SELECT文の教材を注文したい"
  -> W-941一致、score=5、block（誤検知）

SQLという語が業務メモに含まれるだけでDBへSQL文として送られるわけではありません。アプリがパラメータ化した検索を行い、メモをデータとして扱うなら、この要求は正規の可能性があります。反対にシグネチャが反応しない表記でも、アプリ側に文字列連結の脆弱性があれば攻撃が成立し得ます。

2-1. スコア、処置、実際の危険を分ける

W-941単独の5点で遮断される例に対し、3点の規則が二つ一致して計6点となり遮断される例もあります。しきい値を7へ上げれば両方の要求が通過する可能性があります。誤検知が一件見つかっただけで全サイトのしきい値を上げると、ほかの経路で今まで止めていた攻撃も通します。

WAFによってはblock以外にchallengeやlogのみの処置があります。challengeを出した記録は、利用者が最終的に通過したかまで示しません。処置の意味を製品設定で確かめ、アプリログの有無と照合します。

2-2. WAFが見ていない部分

WAFの検査対象と上限は製品・設定で異なります。本文のサイズ上限を超えて一部が切り捨てられた場合、検査されていない後半に攻撃文字列があり得ます。JSON、multipart、圧縮本文、WebSocketなどで、期待するパーサが動くかも確認します。『WAFを通過した』だけで全バイトが検査済みとは言えません。

TLS終端がWAFの手前ではなくアプリ側だけにあるなら、WAFはHTTP本文を読めない構成になります。どこで復号され、どこから再暗号化されるかを構成図で確認します。WAFとアプリのHTTP解釈差があると、WAFが見たパス・本文とアプリが処理したものがずれる場合があります。

2-3. WAFとアプリの解析差

WAFがURLを一回だけデコードし、アプリが後段で再度デコードする場合、両者が同じ文字列を見ていない可能性があります。重複したクエリパラメータでWAFは先頭、アプリは末尾を採用する場合も同様です。入力の正規化、HTTPの曖昧な要求の拒否、アプリ側の安全な実装が必要です。

JSON本文の一部だけを検査する設定や、APIの新しいパスが対象ルールから漏れた状態も見逃しを作ります。新API追加時にはWAFの対象ホスト・パス・メソッド・本文形式を確認し、アプリと同じ意味の入力を検査できるかテストします。WAFの対象であることと、適切な規則が有効であることも別です。

3. 一件の要求がどう処理されるか

図ではWAF内部の規則評価を自己矢印から省略しています。WAFがblockを選べばアプリへの転送は行われず、WAF自身が拒否応答を返します。passならアプリへ届きますが、アプリ側の認可、DB問い合わせ、業務結果が成功したとは限りません。

4. 架空ログで誤検知と見逃しを切り分ける

次のログは同じ検索APIの二件です。WAFのルール名とスコアは架空で、request_idはWAFとアプリの相関用です。時刻はUTC。本文全体は記録せず、必要な検査結果だけを記載します。

13:00:00 waf req=W1 path=/api/orders/search
  rule=W-941 score=5 action=block
  field=query body_truncated=false
13:00:00 app req=W1 record=none

13:05:00 waf req=W2 path=/api/orders/search
  rule=none score=0 action=pass
  field=query body_truncated=false
13:05:00 app req=W2 user=bob status=200
  db_query=parameterized result_count=4

W1が誤検知かどうかは正規利用者の入力と業務目的を調べて決めます。W2が攻撃であったとしてもWAFが見逃しただけではDB侵害は確定しません。アプリの処理、エラー、DB監査、外向き通信を合わせて判断します。

5. 誤検知を直すときに防御を残す

W1が正規の注文メモだと確認できた場合、W-941をサイト全体で無効にするのは影響が大きすぎます。/api/orders/searchのqueryという一つの入力に限定した例外を検討し、別のパラメータや管理APIではルールを維持します。例外条件には対象ホスト、パス、メソッド、パラメータ、期限、承認者を記録します。

例外を設定する前に、WAFが何を正規化して比較するか、アプリが実際に何を受け取るか確認します。JSONパーサの違い、重複パラメータ、URLの復号回数の差があると、意図より広い例外や検査回避につながります。正規要求と攻撃テストの両方で効果を測ります。

5-1. 例外の順序と期限

WAF製品によっては、例外ルールが後続の管理ルールより前に評価されます。例外を管理ルールの後へ置いても誤検知の解消に効かず、逆に『全ての管理ルールをスキップ』を先頭へ置けば防御が広く外れます。除外対象のルールIDと適用するリクエスト条件を、実際の評価順で確認します。

期限付き例外には、担当者、発生した誤検知の再現手順、対象API、対象パラメータ、取り除く条件を記録します。リリースでアプリ側の検索仕様が変わったら例外を再評価します。『一度誤検知したから永久に全遮断を解除』では、新たな攻撃経路を見落とします。

6. 攻撃が成立する条件とWAFの限界

攻撃者がオリジンIPを知っても、FWがWAFの送信元以外を拒否すれば直通は成立しません。直通が成立しても、アプリ側に脆弱性がなければDB改変などには至りません。各段階の証拠を分けて書きます。

6-1. 緊急遮断を根本修正へつなぐ

アプリにSQL連結の欠陥が見つかり、修正まで時間が必要なら、WAFで対象APIの攻撃特徴を暫定的に遮断できます。これは仮想パッチとしての使い方です。ただし攻撃者が表現を変えたり直通したりすれば回避され得ます。期限を付け、アプリのパラメータ化、テスト、リリースを別工程で進めます。

アプリ修正後にはWAFの暫定ルールをすぐ外すのではなく、一定期間の検知結果を見て残すべき防御と不要な例外を判断します。WAFで攻撃を見つけた記録が、修正済みコードの安全性を証明するわけではありません。脆弱な入力経路を回帰テストで確認します。

7. 障害と事故後の対処・再開

誤検知なら、遮断された正規要求の範囲と業務影響を調べ、必要な再送やデータ整合性を確認します。見逃しなら、通過した要求のアプリ処理、DB変更、情報流出の証跡を調べます。見逃しを後から遮断しても、過去の不正操作は巻き戻りません。

1. まずWAFの対象ホスト、TLS終端、経路、ルール版、検査上限、例外を一覧化する。

2. 影響するルールをログのみで観測し、正規業務入力とテスト用攻撃入力の両方で判定を測る。

3. 必要ならホスト・パス・パラメータを絞った例外を承認・期限付きで適用し、アプリ側の根本修正を別に行う。

4. 再開前に正規検索が通り、既知の攻撃入力が止まり、オリジン直通が遮断され、ログ相関ができることを確認する。

WAFのルール更新やアプリの新API追加で誤検知と見逃しの条件は変わります。変更時はヒット件数だけでなく、対象ルール、APIの正常応答、遮断率、例外の使用率、オリジン直通の有無を継続して確認します。ログに機微な検索語や認証ヘッダを無制限に残さないことも必要です。

7-1. 漏えい調査ではログの範囲を明示する

WAFにblockedとある要求は、そのWAFを通る経路でアプリへの転送を止めた材料です。しかしアプリに届いた別要求、WAFの対象外ホスト、ルール適用前の時間帯、オリジン直通を排除できません。アプリ・DBの監査ログと、対象期間のWAF設定変更を合わせて調べます。

検索語やAuthorizationヘッダをWAFに全文保存すると、監査ログ自身が機微情報の保管先になります。調査に必要なrule ID、フィールド名、要求ID、処置、切捨て状態を基本にし、ペイロード保管が必要な場合はアクセス権、暗号化、保持期間を別に管理します。

8. 科目B（午後）の記述演習

演習1：ルール一致の意味

条件：WAFがW-941に一致し要求をblockした。問い：SQL注入の成立とデータ流出を断定できるか。

解答：断定できない。WAFが特徴を検出し、この経路ではアプリへの転送を止めたと分かる。正規入力の誤検知か、別経路・以前の成功があったかは追加調査が要る。誤答『一致したのでDBが侵害された』は検知と影響を混同する。

演習2：サイト全体の除外

条件：/api/orders/searchのqueryで誤検知が続く。運用者はW-941を全ホストで無効化したい。問い：より適切な対応を述べよ。

解答：正規入力とAPI仕様を確認し、必要なら対象ホスト・パス・パラメータだけに期限付き例外を設定する。アプリのDB処理も確認する。誤答『全ホスト無効化』は無関係な入力の検査まで失う。

演習3：WAF通過の解釈

条件：W2はscore=0でpassし、アプリは200を返した。問い：安全を断定できない理由を述べよ。

解答：未知手法や検査範囲外はWAFを通り得る。200はアプリ応答であり認可の正しさやDBへの影響を保証しない。誤答『WAFが無反応なので無害』は見逃しの可能性を無視する。

演習4：本文切捨て

条件：WAFログにbody_truncated=trueとあり、同じ要求がアプリに届いた。問い：調査することを述べよ。

解答：検査上限と実際に未検査だった本文、アプリの解析結果、処理ログを調べる。必要なら大きな本文の扱いを拒否又は別検査へ変える。誤答『WAFを通ったので全本文検査済み』は切捨て記録に反する。

演習5：オリジン直通

条件：WAFに該当ログがなく、アプリに直接接続元からの要求がある。問い：対策と追加証拠を述べよ。

解答：オリジンのFWでWAF送信元だけを許し、公開IP・IPv6・管理経路を調べる。アプリの接続元ログとネットワーク記録を照合する。誤答『WAFログがないので通信なし』は直通経路を無視する。

演習6：しきい値変更

条件：正規の検索一件が5点で誤遮断された。運用者は全サイトのしきい値を7へ上げたい。問い：影響する他要求と代案を述べよ。

解答：5点や6点で従来遮断された攻撃も通る可能性がある。対象APIのqueryに限った除外や入力仕様の調整を検討し、攻撃テストを続ける。誤答『数値を上げれば誤検知だけ消える』は見逃しの増加を無視する。

9. 一次資料

OWASP CRS：アノマリースコアの仕組み

Cloudflare WAF：Managed Rulesと例外

Cloudflare WAF：誤検知の調査

NIST SP 800-44 Version 2：公開Webサーバの保護

OWASP：SQL Injection Prevention Cheat Sheet