WAFの役割と限界、正しい使い方。シグネチャと振る舞い、回避される前提、根本対策との補完

WAF（Web Application Firewall）は、WebアプリケーションとHTTP通信をやり取りする経路に置かれ、リクエストやレスポンスの中身を検査して、攻撃と判断した通信を遮断する仕組みです。SQLインジェクションやクロスサイトスクリプティング（XSS）のような、Webアプリの脆弱性を突く攻撃を、アプリ本体に手を入れずに前段で止められる点が大きな魅力です。脆弱性が見つかってから修正をリリースするまでの間、攻撃を一時的に防ぐ「仮想パッチ」としても使えます。

一方で、WAFを入れさえすれば安全になる、という理解は危険です。WAFは「正規の通信に紛れた攻撃を、限られた情報から推測して見分ける」装置であり、その性質上、見逃し（検知漏れ）も巻き込み（過検知）もゼロにはできません。攻撃者側はWAFを回避するための手法を日々研究しており、WAFを過信してアプリ側の作り込みを怠ると、回避された瞬間に無防備になります。

この記事では、WAFがどういう原理で攻撃を見分けているのか、シグネチャ検知と振る舞い検知という2つの軸から噛み砕きます。そのうえで、WAFが構造的に回避されうる前提、誤検知をどう扱うか、そして「根本対策（アプリの修正）」とどう補完し合うべきかを、実務での判断基準とあわせて整理します。導入を検討している方も、すでに運用している方も、WAFの守備範囲を正しく見積もる助けになれば幸いです。

WAFの位置づけを早見表で押さえる#

まず、WAFが他の防御手段と何が違うのかを整理します。同じ「ファイアウォール」という言葉が付いていても、ネットワークファイアウォールとWAFは見ている層がまったく異なります。

この表で重要なのは、3つが互いに代替ではなく補完だという点です。ネットワークファイアウォールはHTTPの中身を見ないためSQLインジェクションを止められず、WAFは攻撃を推測で判定するため確実ではなく、根本対策は確実だが時間がかかります。だからこそ層を重ねるわけです。WAFはこの中で「アプリを直さずに、いますぐ、アプリ層の攻撃を減らす」という独特の役割を担います。

シグネチャ検知: 既知の攻撃パターンと照合する#

WAFの古典的かつ中心的な仕組みが、シグネチャ（または「ルール」「パターン」）による検知です。これは、過去に観測された攻撃や、攻撃に特徴的な文字列のパターンをあらかじめ用意しておき、流れてくるリクエストがそのパターンに一致するかを照合する方式です。たとえばSQLインジェクションでよく現れる文字列（コメント記号やUNION SELECTのような構文断片）、XSSで使われるスクリプトタグの形などを定義しておき、合致すれば遮断します。

このパターン集として広く使われているのが、OWASPが公開しているCRS（Core Rule Set）です。CRSはModSecurityや互換WAFで使える汎用的な攻撃検知ルールの集合で、SQLインジェクション・XSS・ローカルファイルインクルージョンなど、OWASP Top 10に挙がるような攻撃カテゴリを幅広くカバーします。多くのクラウドWAFも、このCRSをベースにしたマネージドルールを提供しています。

シグネチャ検知の強みは、既知の攻撃に対して高速かつ安定して反応しやすいことです。一方で弱点は、「既知のパターンしか見られない」という点に尽きます。まだ知られていない攻撃や、既知の攻撃をわずかに変形させたものは、パターンに一致せず通り抜ける可能性があります。ここがシグネチャ依存の限界であり、後述する回避の話に直結します。

OWASP CRSは「ModSecurityや互換WAFで使う汎用的な攻撃検知ルールの集合」と位置づけられ、誤検知を抑えつつ主要な攻撃カテゴリを防ぐことを目指しています。CRS 4系では4.25.0が最初の長期サポート(LTS)版として案内されています(本記事執筆時点)。古いCRS 3.3系は提供終了が予告されているため、利用中なら移行計画の確認が必要です。

スコアリングと「異常スコア」という考え方#

シグネチャに関連して、CRSをはじめ現代のWAFが採用するのが「異常スコアリング（anomaly scoring）」という考え方です。これは、1つのルールに一致したら即遮断するのではなく、合致したルールごとに点数を加算し、合計が閾値を超えたら遮断する方式です。

なぜこんな仕組みにするのか。単一ルールでの即時遮断は、たまたまそのパターンを含む正常な通信まで止めてしまいやすいからです。たとえば文章中にSQLのキーワードらしき単語が含まれる投稿は、攻撃でなくても単一ルールに引っかかりえます。スコアリングなら「複数の疑わしい特徴が積み重なったときに遮断する」という、より文脈を踏まえた判断ができ、過検知を抑えやすくなります。

実務では、この調整が運用の中核になります。CRSでは調整の軸が大きく2つあり、混同しないことが大切です。1つはパラノイアレベルで、これは「どれだけ多くの（厳しい）ルールを有効にするか」を決めます。もう1つは異常スコアの遮断閾値で、これは「合計スコアがいくつに達したら遮断するか」を決めます。両者は別概念で、CRSのドキュメントでも「直接の関係がない別物」と整理されています。遮断閾値を上げれば過検知は減りますが検知漏れが増え、下げれば検知漏れは減りますが過検知が増えます。後述する誤検知のトレードオフは、まさにこのつまみを回す作業として現れます。

振る舞い検知: 正常からの逸脱を捉える#

もう一方の軸が、振る舞い（ふるまい）検知です。これは個別の攻撃パターンを照合するのではなく、「正常な通信とはこういうものだ」という基準（ベースライン）を学習・定義しておき、そこから大きく外れた通信を異常とみなす方式です。ポジティブセキュリティモデル（許可リスト型）とも呼ばれ、「正常を定義してそれ以外を弾く」という発想です。これに対しシグネチャ検知は、ネガティブセキュリティモデル（拒否リスト型）にあたります。

振る舞い検知の強みは、未知の攻撃に対応できる可能性があることです。攻撃のパターンを知らなくても、「このパラメータは普段は数字しか入らないのに、急に長い文字列やスクリプトらしき内容が入ってきた」といった逸脱を捉えられます。シグネチャでは追いきれない、既知パターンの変形や新手の攻撃に対する網になりえます。

ただし弱点もあります。「正常」を正しく定義するのが難しく、アプリの仕様変更や利用パターンの変化で正常範囲がずれると、過検知が増えたり逆に異常を見逃したりします。学習期間中に攻撃が紛れ込めば、それを「正常」として取り込んでしまう危険もあります。実際の製品では、シグネチャ検知と振る舞い検知を組み合わせ、互いの弱点を補う構成が一般的です。

なぜWAFは回避されうるのか#

WAFを正しく使ううえで、最も理解しておくべきなのが「回避（bypass, evasion）が原理的に起こりうる」という前提です。これはWAFの欠陥というより、構造に由来する性質です。

WAFは、アプリが最終的にその入力をどう解釈するかを完全には知らないまま、リクエストの見た目から攻撃かどうかを推測します。ところが、同じ意味を持つ入力には無数の表現の揺れがあります。たとえば文字をURLエンコードや二重エンコードで隠す、大文字小文字を混ぜる、コメントや空白を挿入して構文を分断する、別の文字コードで表現する、といった変形です。WAFが「この表現」を攻撃と認識していても、攻撃者が等価な別表現を使えば、パターンに一致せず通過してしまうことがあります。WAFとアプリで入力の解釈がずれる（パーサの差異）ことが、回避の根本原因です。

実際、CRSのようなルールセットも、こうした回避テクニックへの対応を継続的に更新しています。たとえば空白を使った検知ロジックの迂回といった手法が見つかれば、それを塞ぐ修正が入ります（執筆時点のCRSでもそうした回避対策の更新が継続しています）。これは裏を返せば、「WAFは常にいたちごっこの渦中にあり、ある時点のルールが将来も万全とは限らない」ということでもあります。

ここから導かれる実務上の結論は明確です。WAFは攻撃の量と成功率を下げる確率的な防御であって、特定の脆弱性を確実に塞ぐものではありません。SQLインジェクションを本当に「塞ぐ」のは、後述するようにアプリ側でプレースホルダ（プリペアドステートメント）を使う根本対策です。WAFはその修正が完了するまでの時間を稼ぎ、検知できなかった分の被害確率を下げる、という位置づけで捉えるのが正確です。

SQLインジェクションそのものの原理と根本対策については

過検知と検知漏れ: 運用の本体はこのトレードオフ#

WAF運用の現実は、「どこまで厳しく弾き、どこまで通すか」という調整の連続です。ここで避けて通れないのが、過検知（フォールスポジティブ）と検知漏れ（フォールスネガティブ）という2種類の誤りです。

過検知は、攻撃ではない正常な通信を攻撃と誤判定して遮断してしまうことです。利用者がエラーになり、問い合わせが増え、最悪の場合は正規の業務が止まります。検知漏れは逆に、本物の攻撃を見逃して通してしまうことです。どちらもゼロにはできず、しかも一方を減らそうとすると他方が増える、というトレードオフの関係にあります。閾値を厳しくすれば検知漏れは減るが過検知が増え、緩めれば過検知は減るが検知漏れが増える、という構図は先のスコアリングの話と同じです。

実務では、この調整を一度きりで終わらせず、継続的に回す必要があります。アプリは変わり続け、新しい正常パターンや新しい攻撃手法が増えるからです。そのため、いきなり遮断モードで本番投入するのではなく、まず「検知（検出）モード」で記録だけを取り、ログから過検知を洗い出してルールを除外・調整し、十分に枯れてから遮断モードへ切り替える、という段階的な進め方が定石です。

WAFと根本対策はどう補完し合うか#

ここまでの議論を踏まえると、WAFの正しい使い方は「根本対策を置き換えるものではなく、補完するもの」と整理できます。IPAの資料でも、脆弱性をなくす根本的な解決策と、攻撃の影響を軽減する保険的な対策は別物として位置づけられており、WAFは後者、すなわち保険的・時間稼ぎの対策にあたります。

具体的な補完の形は、おおむね次のような流れになります。

逆に避けたいのは、「WAFを入れたから脆弱性は直さなくてよい」という発想です。WAFは回避されうる以上、根本対策を怠れば回避された瞬間に被害が出ます。WAFのログは、どの脆弱性がどれだけ狙われているかを教えてくれる貴重な情報源でもあります。遮断して終わりにせず、ログを根本対策の優先順位付けに活かすのが、攻めの運用です。

なお、WAFには可用性に関わる攻撃を緩和する機能（レート制限やBot対策など）を備えるものもありますが、回線帯域を埋めるタイプのDDoSはWAFが処理する前に回線が詰まるため、WAF単独では防げません。可用性の観点での使い分けは

IPA「安全なウェブサイトの作り方」は、SQLインジェクションやXSSなど主要な脆弱性について、根本的な解決策と保険的な対策を分けて示しています。WAFは保険的対策の位置づけであり、まず根本対策で脆弱性そのものをなくすことが推奨されています。

よくある質問#

まとめ#

WAFは、アプリに手を入れずにアプリ層の攻撃をいますぐ減らせる、運用上きわめて有用な道具です。しかし「推測で見分ける」という性質上、回避も誤検知も避けられません。だからこそ、根本対策を置き換えるのではなく補完するものとして位置づけ、検知モードからの段階導入と継続的なチューニングをセットで考えることが、WAFを活かす鍵になります。攻撃側の原理は