WAF とアプリ層防御の原理（シグネチャ・正値/負値モデル）

WAF とは何を検査する層か

WAF（Web Application Firewall）は、HTTP/HTTPS リクエストの中身（メソッド・パス・ヘッダ・クエリ・ボディ）を検査し、攻撃と判断したものをアプリに届く前に遮断するアプリケーション層のフィルタです。L3/L4 のファイアウォールが IP やポートを見るのに対し、WAF は L7 のペイロードを解釈する点が決定的に異なります。

配置はリバースプロキシ形態が一般的で、TLS を終端してから平文の HTTP を検査します。つまり WAF はTLSの内側に立ち、復号済みのリクエストを文字列として観測する外付けの番兵です。アプリのコードには手を入れず、SQL インジェクションやXSS、SSRF といった OWASP Top 10 級の攻撃パターンを経路上で止めるのが役割です。

重要なのは、WAF がアプリの内部状態を一切知らないことです。あるパラメータが最終的に SQL クエリに渡るのか、HTML に出力されるのか、ファイルパスになるのかを WAF は確定できません。だからこそ「文字列が攻撃に見えるかどうか」で判断するしかなく、これが誤検知と回避の根本原因になります。

二つのセキュリティモデル：負値と正値

WAF の判定ロジックは大きく二系統に分かれます。どちらを採るかで誤検知率と未知攻撃への耐性が裏返しになります。

ネガティブモデルは「攻撃の特徴量」をシグネチャ（正規表現や演算子の組）として持ち、リクエストがそれに一致すれば弾きます。UNION SELECT や ' OR '1'='1、<script>、../ などが典型のパターンです。デプロイが容易で正規トラフィックを邪魔しにくい反面、シグネチャに無い亜種は原理的に検出できません。

ポジティブモデルは逆に「正しい入力の集合」を定義し、その集合 {許可された形} の外を全て拒否します。たとえば「user_id は数字 1〜10 桁のみ」と定めれば、UNION だろうが未知の攻撃だろうが形が合わない時点で落ちます。未知攻撃に強い理想形ですが、全エンドポイントの正規入力を漏れなく定義する必要があり、仕様変更のたびに維持コストがかかります。

実運用の WAF は両者を組み合わせ、シグネチャをベースにしつつ重要パラメータだけ厳格な正値ルールを被せる構成が多くなります。

スコアリングと異常検知

近年の主流ルールセット（OWASP CRS など）は、単一ルールの一致で即遮断する代わりに異常スコア（anomaly scoring）を積み上げます。各ルールに重み（critical=5、warning=3 など）を与え、リクエスト中で一致したルールの合計が閾値以上なら遮断する方式です。

score = 0
各ルール r について:
    if r.matches(request):
        score += r.severity_weight
if score >= inbound_threshold:   # 例: 5
    block(request)

この設計は、単独では弱い兆候（怪しい記号が1個ある程度）を1件で誤遮断しないための工夫です。閾値を上げれば誤検知が減るが見逃しが増え、下げればその逆になる。閾値は検出力と可用性のトレードオフを一つのつまみで握るパラメータであり、チューニングの中心になります。

機械学習型は正規トラフィックから統計的ベースラインを学習し、分布から外れたリクエストを異常として扱います。新種を捉えうる一方、学習データに攻撃が混じればそれを正常と学習してしまう毒性に注意が要ります。

正規化と回避：WAF とアプリのズレ

WAF 回避の本質は一言で言える。WAF が検査する文字列と、アプリが最終的に解釈する文字列が一致しないことです。攻撃者はこのズレを突く。

WAF は検査前に**正規化（normalization / canonicalization）**を行います。URL デコード、Unicode 正規化、大文字小文字の畳み込み、連続スペースやコメントの除去などを施し、表記の揺れを潰してからシグネチャに掛けます。ここで処理しきれない変形が回避経路になります。

たとえば %2553ELECT は、WAF が1段だけ URL デコードすると %53ELECT のまま（攻撃に見えない）だが、アプリ側がもう一段デコードすると SELECT に化ける。デコード回数の非対称性が突破口です。同様に HTTP リクエストスマグリングは、フロントの WAF とバックのアプリでリクエスト境界の解釈がズレることを悪用します。

誤検知とチューニング

ネガティブモデルの宿命が**誤検知（false positive）**です。正規ユーザーの入力がたまたまシグネチャに一致し、正当な操作が遮断される。記事本文に <script> という文字列を含む CMS への投稿、SQL の解説を投稿する技術ブログ、' を含む人名などが典型です。誤検知は可用性を直接損ない、放置すると現場が WAF を無効化する圧力になります。

チューニングの定石は段階的です。

• 検知のみモード（detection-only）で運用し、遮断せず違反だけ記録する。本番トラフィックでどのルールがどれだけ反応するかを実測する。
• 誤検知の多いルールを特定し、例外（exclusion）を定義する。「この URL のこのパラメータではこのルールを無効化」と範囲を絞って除外するのが鉄則で、ルールごと全面オフにすると防御が穴だらけになる。
• 異常スコアの閾値を調整し、可用性と検出力のバランス点を探す。
• ログを継続監視し、アプリ更新のたびに再評価する。

レート異常への対処は別軸で、攻撃の試行回数そのものを抑えるレート制限と組み合わせると、WAF が個々のペイロードを取りこぼしても総当たりの成立を遅らせられます。

WAF と RASP の違い

WAF の限界（文脈を持てない・正規化のズレで回避される）を構造的に解く別アプローチが **RASP（Runtime Application Self-Protection）**です。

WAF が通信経路上で文字列を外から見るのに対し、RASP はアプリのランタイム内部に埋め込まれ、SQL ドライバの実行直前、OS コマンド呼び出し地点、ファイルオープン地点といった危険な操作の実行点で監視します。決定的な違いは、RASP がそのデータが実際にどう使われるかという文脈を持つことです。

• WAF は「' OR 1=1 という文字列がクエリに見えるか」を推測する。
• RASP は「この入力が SQL 構文を改変したか」を、パース後の実際のクエリ構造を見て判定できる。

このため RASP は正規化のズレに左右されにくく、誤検知も理屈の上では減ります。実際、入力がどんなエンコードで来ても、最終的に SQL 文を構造的に書き換えた瞬間を捉えられる。

ただし RASP は言語ランタイムへの計装（エージェント組み込み）が前提で、対応言語が限られ、性能オーバーヘッドも生じます。WAF は逆にアプリを改変せず前段に置けて広く構えられる。両者は競合ではなく、入口で広く弾く WAF と、実行点で精密に止める RASPという多層防御の異なる層として併用するのが定石です。

まとめ

WAF は HTTP リクエストを正規化して検査するアプリ層フィルタで、既知攻撃を弾くネガティブモデルと許可形だけ通すポジティブモデルを組み合わせ、異常スコアの閾値で遮断します。回避の本質はWAF が見る文字列とアプリが解釈する文字列のズレにあり、検出力は正規化の網羅性でほぼ決まります。誤検知は検知のみモードと範囲を絞った例外で抑えるのが定石で、可用性と検出力のトレードオフをチューニングで握ります。アプリ内部の文脈を持てない WAF の限界は、実行点で監視する RASP が補い、両者は多層防御の異なる層として併用します。WAF は脆弱性そのものを直す代替ではなく、セキュリティヘッダや入力検証と重ねてこそ効果が出る防御層です。