WAF の中で何が起きているのかを、図を動かして追います。リクエストの分解・正規化・ルールの照合と採点・判定の4段、誤検知と例外、パラノイアレベル、肯定モデルと否定モデル、読める長さの上限や読み方のずれによるすり抜け、オリジンへの直撃、仮想パッチ、最近の動きまで。
大量の通信で押しつぶす攻撃は、量を見れば見分けられます。けれども、たった1本のリクエストの中身で仕掛ける攻撃もあります。検索窓に検索語のふりをして SQL の断片を入れる SQL インジェクション、入力欄に JavaScript を混ぜる XSS、../ で見せてはいけないファイルを読むパストラバーサル、公開済みの脆弱性を突くリクエストなどです。
こうした攻撃は、送り方も宛先もふつうのアクセスと変わりません。違うのは、封筒の中に入っている文字だけです。
このアニメモでは、その中身を読んで止める WAF（Web Application Firewall）が中で何をしているのかを、図を動かしながら追っていきます。特定の製品ではなく、多くの WAF に共通する考え方を扱い、例としてオープンソースの WAF で広く使われているルール集 OWASP CRS の仕組みをよく参照します。
ふつうのファイアウォールは、通信の送り元と宛先（IP アドレスとポート番号）を見て、通すかどうかを決めます。Web サイトなら「443番（HTTPS）への通信は許可」と設定するので、その番号宛ての通信はすべて通ります。
封筒にたとえると、ファイアウォールは表に書かれた宛先を確かめるだけで、封筒を開けません。中に SQL インジェクションの文字列が入っていても、宛先が正しければそのままアプリまで届きます。
ネットワークの層でいうと、ファイアウォールが見るのは主に第3層（IP）と第4層（TCP・UDP）です。HTTP の中身は第7層（アプリケーション層）にあり、そこを読むには別の仕組みが要ります。
WAF は、アプリの手前に立って HTTP のリクエストを開けて読みます。読む場所は、URL のパスとクエリ、ヘッダー、Cookie、そしてフォームや JSON で送られる本文です。そこに攻撃の型が含まれていれば止め、問題がなければアプリへ渡します。
HTTPS の通信は暗号化されているので、WAF が中身を読むには、WAF の位置で暗号をいったん解く必要があります。CDN やロードバランサーに組み込まれた WAF が多いのは、そこがもともと暗号を解く場所だからでもあります。
WAF はファイアウォールの代わりではなく、見る層が違う別の守りです。ファイアウォールが番号で絞り、WAF が中身で絞ります。
WAF の中で起きていることは、大きく4つの段に分けられます。
| 段 | やること |
|---|---|
| ① 分解 | 文字の並びとして届いたリクエストを、メソッド・パス・引数・ヘッダー・Cookie・本文などの項目に分ける |
| ② 正規化 | URL エンコードや大文字小文字などの「変装」をほどき、ルールが比べやすい形にそろえる |
| ③ 照合と採点 | 項目ごとにルールを当て、当たったルールの重さに応じて点を足す |
| ④ 判定 | 合計点をしきい値と比べ、止める・通す・記録だけにするを決める |
ここから先は、この4段を1つずつ開けて見ていきます。次のページから上に並ぶ帯が、いまどの段にいるかの目印です。
※③と④を点数で分ける作りは OWASP CRS の方式です。製品によっては、1本のルールが当たった時点で止める作りもあります。
WAF に届くリクエストは、改行で区切られた1本の文字の並びです。1行目にメソッドとパスとプロトコル、続いてヘッダーが並び、空行のあとに本文が続きます。
ルールで調べるには、まずこれを項目に分けなければなりません。どこまでがパスでどこからがクエリか、本文はフォームなのか JSON なのか。本文の形式は Content-Type ヘッダーが告げるので、WAF はそれを見て本文の読み方を切り替えます。
この「読み方」が、後で出てくるすり抜けの大きな原因になります。WAF とアプリが同じリクエストを違うふうに読めば、WAF が調べた中身と、アプリが実際に受け取る中身がずれてしまうからです。
分解が終わると、リクエストは項目と値の表になります。パスは /search、本文の引数 q の値は %27%20oR%201%3D1%20--、というように、どの値がどこに入っていたかが分かる形です。
WAF のルールは、この表の項目を指定して書かれます。「すべての引数の値を見る」「Cookie を見る」「ヘッダー User-Agent を見る」といった具合です。ModSecurity 系の WAF では、引数をまとめて ARGS、ヘッダーを REQUEST_HEADERS のように呼びます。
ただし、表にした段階の値は、まだ送られてきたままの形です。図の q は %27 のような記号の並びで、このままでは SQL の断片には見えません。そこで次の段で、変装をほどきます。
同じ攻撃でも、書き方はいくらでも変えられます。' を %27 と URL エンコードする、OR を oR と大文字小文字を混ぜる、空白の代わりに /**/ のようなコメントを挟む、といった具合です。アプリ側は受け取ったあとでこれらを元に戻して解釈するので、攻撃としては同じように効きます。
ルールをすべての変装パターンについて書くのは不可能です。そこで WAF は、ルールに当てる前に値を決まった形にそろえます。これを正規化と呼びます。ModSecurity 系では、URL デコード（urlDecodeUni）、HTML の文字参照の解除（htmlEntityDecode）、小文字化（lowercase）、空白の圧縮などの変換関数を、ルールごとに指定して順に掛けます。
順番には意味があります。たとえば先に小文字にしてから URL デコードすると、%4F が後から大文字の O に戻って小文字化をすり抜けます。デコードしてから小文字にするのが基本です。
2つの変換を通ると、%27%20oR%201%3D1%20-- は ' or 1=1 -- になりました。ここまで来れば、「引用符のあとに or と常に真になる比較が続く」という SQL インジェクションの型にそのまま当てられます。
変換するのは、WAF の中で作った検査用の写しです。ModSecurity の説明でも、変換関数はメモリ上の写しに掛けられ、元のリクエストは書き換えないとされています。アプリには、送られてきたままのリクエストが渡ります。
ここに WAF の難しさが1つあります。WAF の戻し方とアプリの戻し方が食い違うと、WAF は無害だと判断したのに、アプリでは攻撃として働く、ということが起こります。正規化は、アプリがどう解釈するかを WAF が真似する作業でもあるのです。
正規化した値に、ルールを順番に当てていきます。OWASP CRS では、ルールが当たってもその場では止めません。代わりに、そのリクエストの異常スコアに点を足し、次のルールへ進みます。CRS はこれを「協調検知（collaborative detection）」と呼んでいます。
足す点は、ルールの重さ（severity）で決まっています。
| 重さ | 既定の点 |
|---|---|
| CRITICAL | 5 |
| ERROR | 4 |
| WARNING | 3 |
| NOTICE | 2 |
図では、最初のルール（引用符のあとに常に真になる比較）が当たり、5点が入りました。図のルール名と点の付き方は、説明のための例です。
ほかのルールも当たり、合計は13点になりました。本物の攻撃は、いくつものルールに同時に引っかかることが多いので、点は大きくなりがちです。CRS の説明では、SQL インジェクションだけで50本以上のルールがあり、実際の攻撃は15点や20点を超えることもあるとされています。
一方、XSS やパストラバーサルのルールには当たっていません。ルールは攻撃の種類ごとに束になっていて、どのリクエストにもすべての束が当てられます。
点数方式のよいところは、検知と判定を切り離せることです。1本のルールだけでは決め手に欠ける小さな兆候も点として残しておき、最後に合計で判断できます。
リクエストを調べるルールがすべて終わったところで、合計点をしきい値と比べます。CRS の既定では、リクエストのしきい値は5点です。13点のリクエストは止められ、アプリには届かずに 403 などのエラーが返ります。ふつうの検索のように0点なら、そのままアプリへ渡ります。
既定値が5点なのは、CRITICAL のルールが1本当たっただけで止めるためです。CRS は、しきい値を上げると攻撃をすり抜けさせることになるので、上げるのは誤検知を調整する間の一時的な措置にとどめるよう注意しています。
判定は応答（レスポンス）にもあります。アプリが返す中身に情報漏れなどの兆候があれば点を足し、既定では4点以上で応答を止めます。止め方は「止める」だけでなく、「記録だけして通す」や、ブラウザに確認を挟む方式を選べる製品も多くあります。
WAF は「攻撃に見えるか」を判断しているので、攻撃ではない正しいリクエストを止めてしまうことがあります。これを誤検知（false positive）と呼びます。
図は、技術ブログの管理画面で、SQL の例を含む記事を保存しようとした場面です。本文に SELECT * FROM users -- が入っているので SQL インジェクションのルールが当たり、合計がしきい値を超えて止められました。利用者から見ると「記事が保存できない」という、原因の分かりにくい不具合です。
ほかにも、外部サービスから届く Webhook の本文、HTML を含む入力欄、長いトークンを入れた Cookie などが誤検知を起こしやすい場所です。CRS は、誤検知を本物の攻撃と混ぜたまま放っておくのは危ないとして、きちんと取り除くよう求めています。
誤検知は、ルールの例外を作って取り除きます。CRS の資料では、例外はできるだけ狭く書き、ルールをまるごと外すより、パスや引数を限った例外を選ぶよう勧めています。
図では、「パス /admin/posts の引数 content にだけ、当たっていた2本の SQL のルールを当てない」という例外を作りました。同じルールは、ほかのページやほかの引数では引き続き働きます。記事は保存できるようになり、合計点は0点に戻りました。
反対に「SQL のルールをサイト全体でオフにする」ような広い例外は、誤検知と一緒に本物の攻撃まで通してしまいます。例外を作るときは、どのルールを、どのパスの、どの項目で外すのかを必ずそろえて書きます。WordPress などよく使われるアプリ向けには、CRS が例外の詰め合わせ（プラグイン）を用意しています。
WAF を新しく入れるとき、いきなり既定のしきい値で止め始めると、誤検知で正しい利用者まで止めてしまうおそれがあります。よく使われる進め方は2つあります。
1つは、止めずに記録だけする検知モードでしばらく動かし、ログを見て誤検知に例外を作ってから止め始める方法です。もう1つは CRS の資料が紹介している方法で、最初から止める設定にしつつ、しきい値を10000のような非常に高い値にしておき、誤検知を取り除きながら段階的に下げていきます。
後者のよいところは、止める仕組みそのものが最初から本番で動いていることです。しきい値を下げる各段で、ログに出た誤検知を例外で消し、静かになったら次の段へ進みます。最後に既定の5点まで下げれば完了です。図の途中の値は一例です。
CRS には、ルールの厳しさを4段階で切り替えるパラノイアレベル（PL）があります。レベルを上げるほど、より細かく疑い深いルールが有効になります。
| レベル | 中身 |
|---|---|
| PL1（既定） | 主なルールが有効。誤検知はまれで、どのサイトにも勧められる |
| PL2 | 正規表現による SQL インジェクションや XSS の検出などが加わる。誤検知への対応が必要になる |
| PL3 | あまり見られない攻撃向けのルールや語のリストが加わる |
| PL4 | 特殊な文字をさらに強く制限する |
レベルを上げると攻撃は逃しにくくなりますが、誤検知が増え、それを取り除く手間も増えます。CRS は、レベルを下げれば誤検知は必ず減る作りになっていると説明しています。図の棒の長さは傾向を示すためのもので、実測値ではありません。
つまみを PL3 まで回すと、有効なルールが増え、すり抜ける攻撃は減ります。その代わり、誤検知がぐっと増えます。CRS も、十分な調整なしに高いレベルで止め始めるのは非常に危険だとしています。
そこで CRS には、止めるレベルと検知するレベルを分けて設定する仕組みがあります。たとえば止めるのは PL1 のまま、検知だけ PL2 まで広げておくと、PL2 のルールの当たり方をログで観察できます。誤検知に例外を作り終えてから、止めるレベルを PL2 に上げます。
どのレベルが正しいかは、サイトの重要さと、誤検知に向き合える人手で決まります。ログを見る人がいないまま高いレベルにすると、守りではなく障害の原因になります。
ここまで見てきたルールは、「SQL インジェクションはこういう型」という悪い型の一覧でした。これを否定モデル（negative security model）と呼びます。どのサイトにもそのまま使える反面、一覧に載っていない新しい攻撃は通してしまいます。
反対の考え方が肯定モデル（positive security model）です。「この API には、この形の JSON しか来ない」という正しい形の定義を持ち、それに合わないものをすべて止めます。API なら OpenAPI の仕様書を使って、パス・メソッド・引数の型や長さを検査する方法がよく使われます。
図の四角はふつうのリクエスト、丸は一覧に載っている既知の攻撃、ひし形はまだ誰も知らない新しい攻撃です。次のページで、それぞれを門に通してみます。
動かしてみると違いが分かります。否定モデルは既知の攻撃を止めましたが、一覧にない新しい攻撃は通しました。肯定モデルは、形が仕様に合わないので、新しい攻撃も止めています。
その代わり肯定モデルは、アプリが変わるたびに定義を直さないと、新しく作った正しい機能まで止めてしまいます。そのため実際の WAF は両方を組み合わせることが多く、汎用のルール（否定モデル）を土台に、API の仕様による検査（肯定モデル）を重ねます。
最近は、ルールに一致するかどうかではなく、機械学習で攻撃らしさを点数にする検出を併用する WAF も増えています。たとえば Cloudflare は、既存のルールをすり抜ける変種を捕まえる目的で、1〜99の攻撃スコアをルールと並べて使えるようにしています。
WAF は本文を調べるために、届いた本文をいったんメモリに溜めてから読みます。すべてのリクエストの本文を無制限に溜めることはできないので、多くの WAF には読む長さの上限があります。
たとえば AWS WAF のドキュメントでは、Application Load Balancer に付けた場合は本文の先頭 8KB まで（変更不可）、CloudFront や API Gateway では既定で 16KB までで、追加料金で引き上げられるとされています。Cloudflare も、2025年12月に 1MB へ広げるまでは、本文を溜めて読む範囲が 128KB でした。
上限の内側に攻撃の文字列があれば、これまで見てきた流れで見つけて止められます。問題は、上限の外側にあるときです。
攻撃者が、攻撃の文字列の前に無害なデータを大量に詰めると、攻撃の部分が WAF の読む範囲の外へ押し出されます。WAF は読めた範囲に何もないので通し、アプリは本文を最後まで読んで攻撃を受け取ってしまいます。
対策は、上限を超えた本文の扱いを決めておくことです。AWS WAF には、上限を超えた本文を「読めた分だけ検査する（既定）」「ルールに当たったものとみなす」「当たらなかったものとみなす」から選ぶ設定があり、ルールと組み合わせて上限を超えた本文を止められます。
ファイルのアップロードなど大きな本文が正当な場所だけを例外にし、それ以外では長すぎる本文を止めるのが基本です。既定のままだと「読めた分だけ検査」になる製品があるので、使っている WAF の設定を確かめておきましょう。
①の分解で見たように、WAF は本文の形式を解釈してから中身を調べます。もし WAF とアプリで解釈が食い違えば、WAF が調べた中身と、アプリが受け取る中身が別のものになります。
2025年の ACSAC で発表された研究「WAFFLED」は、この食い違いを系統的に探しました。攻撃の文字列そのものではなく、ヘッダーや本文の区切りといった無害に見える部分を少しずつ崩す方法で、application/json・multipart/form-data・application/xml を対象に、AWS・Azure・Cloud Armor・Cloudflare・ModSecurity の5つの WAF で計1207件のすり抜けを確認しています。また、調べたサイトの9割以上が、フォーム形式と multipart 形式を区別せずに受け付けていたと報告しています。論文（arXiv）
対策の方向は、あいまいなリクエストは通さないことです。WAF は形式が崩れたものを止め、アプリは想定した形式以外を受け付けないようにします。図は仕組みを単純にしたものです。
CDN やクラウドの WAF は、利用者とアプリの間に立つ通り道に置かれます。逆に言えば、WAF が見ているのは、そこを通ってきたリクエストだけです。
もしアプリのサーバー（オリジン）の IP アドレスが知られていれば、攻撃者は WAF を通らず、オリジンへ直接リクエストを送れます。そうなると、どれほどルールを整えても意味がありません。
オリジンの IP は、思わぬところから漏れます。WAF を入れる前の古い DNS の記録、同じサーバーで動いているメール用のサブドメイン、IP アドレスを表示するエラーページ、サーバーから外部へのアクセスなどです。
対策は、オリジン側で WAF からの接続以外を断ることです。よく使われるのは2つの組み合わせです。
1つは、WAF の事業者が公開している IP アドレスの範囲からの接続だけを、オリジンのファイアウォールで許可する方法です。もう1つは、WAF からオリジンへの接続でクライアント証明書を提示させ、証明書のない接続を断る方法（mTLS）です。Cloudflare では Authenticated Origin Pulls という名前で提供されています。IP の制限だけでは、同じ事業者を使う別の利用者からの接続も通ってしまうので、自分専用の証明書と組み合わせるとより確実です。
最後に、攻撃者と同じようにオリジンの IP へ直接接続して、本当に断られるかを確かめます。
WAF が見ているのは、リクエストの形です。形としてはまったくふつうなのに、意味として不正なリクエストは止められません。
代表例が、URL の番号を書き換えて他人のデータを見る攻撃です。注文 1001 の持ち主が /orders/1002 を開いても、リクエストに怪しい文字は1つもありません。これを止められるのは、「この人は注文 1002 を見てよいか」を知っているアプリだけです。同じように、クーポンの使い回しや、決済の手順を飛ばすといった業務の流れの悪用も、WAF の守備範囲の外です。
OWASP Top 10 で長く上位にある「アクセス制御の不備」は、まさにこの種類の問題です。WAF は、アプリの認可やロジックの代わりにはなりません。
ソフトウェアの脆弱性が公表されてから、すべてのアプリが更新を終えるまでには時間がかかります。その間、攻撃の型が分かっていれば、WAF にルールを足して攻撃を手前で止めることができます。これを仮想パッチと呼びます。
2025年12月3日に公表された React Server Components の脆弱性（CVE-2025-55182、通称 React2Shell）は、認証なしでサーバー上のコードを実行できる深刻なものでした。Cloudflare や AWS などは公表前後に対応するルールを配り、アプリの更新までのつなぎとして使われました。
ただし、仮想パッチは穴を塞いだわけではありません。React2Shell でも、配られたルールをすり抜ける攻撃の書き方が次々に報告され、単純な文字の一致だけでは足りないことが分かりました。ルールで時間を稼ぎつつ、アプリの更新を急ぐのが正しい使い方です。図の横軸の長さは目安です。
WAF はすべてのリクエストが通る場所にあるので、WAF 自体の不具合は、そのままサイト全体の障害になります。
React2Shell への対応中の2025年12月5日、Cloudflare は本文を溜めて読む範囲を 128KB から 1MB（Next.js の既定の上限）に広げる変更を配っていました。その途中で、内部の WAF テスト用の仕組みを全体設定で止めたところ、古い世代のプロキシ（FL1）で Managed Ruleset を使っていた利用者でエラーが起き、約25分間、Cloudflare が扱う HTTP 通信の約28%に影響しました。攻撃ではなく、守るための変更が原因でした。Cloudflare の報告
WAF のルールや設定の変更も、アプリの変更と同じく本番への変更です。Cloudflare 自身も、設定も少しずつ配る、すぐ戻せるようにする、設定が壊れていても通信を落とさずに通す方向へ寄せる、といった対策を挙げています。自分で WAF を運用するときも、WAF が応答しないときに通すか止めるかを決めておきます。
WAF の置き場所は、大きく3つに分かれます。
| 置き場所 | 例 | 特徴 |
|---|---|---|
| CDN のエッジ | Cloudflare・Akamai・Fastly など | 世界中の拠点で止めるので、オリジンに届く前に攻撃を減らせる。オリジンの直撃対策が前提 |
| クラウドの入口 | AWS WAF・Azure WAF・Google Cloud Armor など | ロードバランサーや CDN に付け、クラウドの構成と一緒に管理できる |
| Web サーバーの中 | ModSecurity・Coraza に OWASP CRS を載せる | 自分の環境で細かく調整できる。更新や調整は自分で担う |
CRS は特定の製品ではなく、ModSecurity や Go で書かれた Coraza などの互換エンジンで動くルール集です。商用の WAF の中にも、CRS を元にしたルールセットを提供しているものがあります。ただし CRS は、しきい値を既定より高くした実装はすり抜けを生むと注意しています。どこに置いても、中で起きているのはこれまで見た4段の流れです。
オープンソースの WAF では、体制が大きく変わりました。ModSecurity は2024年1月に管理が Trustwave から OWASP へ移り、Trustwave のサポートは2024年7月に終わりました。CRS は ModSecurity に加えて、Go で書かれた互換エンジン Coraza でも動きます。CRS 4.25 は CRS 4 で初めての長期サポート版になり、CRS 3.3 系のサポートは2026年第3四半期で終わります。次の大きな版では、ルールの書き方を YAML ベースの CRSLang に切り替える計画も発表されています。OWASP CRS
ルール自体も、すり抜けとの追いかけっこです。2026年10月2日には CRS 4.30.0 と 4.25.2 LTS が出て、すり抜けにつながる3件の問題が修正されました。WAF は入れて終わりではなく、更新し続けるソフトウェアです。
規格の面では、カード決済を扱う事業者向けの PCI DSS 4.0 で、要件 6.4.2 が2025年3月31日から必須になりました。公開している Web アプリの前に、攻撃を継続的に検知・防止する自動の仕組みを置くことを求めるもので、WAF はその例として挙げられています。
WAF は、ファイアウォールが開けない封筒を開けて、HTTP の中身を読む門番です。中では、分解 → 正規化 → 照合と採点 → 判定の4段で、リクエストを攻撃らしさの点数に変えて判断しています。
うまく使うには、誤検知を狭い例外で取り除きながらしきい値やパラノイアレベルを調整すること、読める長さの上限と超えた分の扱いを決めること、オリジンへの直撃を塞ぐことが欠かせません。
そして WAF は、アプリの穴そのものを無くすものではありません。形が正しい不正は見えず、ルールをすり抜ける書き方も見つかり続けます。WAF で時間を稼ぎ、その間にアプリを直す。両方を組み合わせて、はじめて守りになります。
ログインするとコメントできます。
読み込み中…
権利侵害・不適切な内容の連絡: [email protected]