見えるセキュリティ

WAFの仕組み

WEB APPLICATION FIREWALL

この概念とは？

WAF（Web Application Firewall、ワフ）は、Webアプリへの通信内容を検査し、設定した条件に応じて検知・拒否などを行う仕組みです。たとえばURLのパラメータや本文を調べます。検知だけを記録して通す設定もあり、導入しただけで必ず遮断するわけではありません。[T01・T02]

同じ不審なリクエストを検知したのに、なぜアプリへ届く場合と止まる場合があるのか？

THEME
web-vuln
KIND
defense
REVIEW
self-reviewed ·

同じリクエストとルールで照合し、最後に「検知のみ」と「検知して遮断」の設定別の結果を比較します。

図を見る前に：リクエスト・q・ルール
HTTPリクエスト
ページの取得や検索などを、利用者側からサービス側へ依頼する通信。
パラメータ
検索語など、依頼と一緒に送る値。この例では検索語を表すq。
ルール
どの項目を、どの条件で調べるかを定めたもの。検知後の処理方針と区別します。

TLS終端後のHTTP内容を検査できる構成の図です。実際の通信や攻撃は行いません。

利用者側

検索の依頼を送る

同じ要求

サービス側のWAF

要求は受信済み

受信した要求（原本を保持）

GET /search?q=%27%20OR%201%3D1--

ここで要求を受け止める

これからqを検査します。
まだ照合も転送もしていません。

転送はまだ

Webアプリ

アプリ未到達

ここにはまだ届いていません

STEP 01 / 4

同じリクエストを受け取る

STEP 1 / 4: 同じリクエストを受け取る

現在のSTEP 1STEP 2STEP 3STEP 4

WAFが検索の依頼を受信しました。まだWebアプリには転送していません。

技術的な詳細を見る

GET /search?q=%27%20OR%201%3D1--という固定の要求を、TLS終端後に検査できる構成です。両モードとも利用者からWAFへは受信済みです。TLS終端の手順は省略します。[T01]

パネルの開閉ではSTEPは変わりません。

この概念の要点

  • 要点

    HTTPの内容を、決めた条件と照合する

    WAFはURLの値やヘッダー・本文などを検査する。この図ではqの値と教材ルールを比較する。[T01]

  • 要点

    検知と遮断は別の段階

    同じ一致結果でも、記録して転送する設定と拒否する設定がある。実際の判定にはスコア等を使う方式もある。[T01・T03]

  • 要点

    誤検知・見逃しと、根本対策を考える

    正常な入力も一致し得る。WAFを通っただけでは安全とはいえず、ルールの運用とアプリの修正を併用する。[T02・T04・T05]

理解確認

同じ要求が教材ルールAに一致したのに、設定によってWebアプリへ届く場合と届かない場合がある理由は？

理解確認

正当な検索語「OR 1=1 の意味」が教材ルールAで検知された。まず何を考える？

理解確認

検索語に「OR 1=1」を含むリクエストをWAFが拒否した後、アプリのSQLインジェクション対策は不要になる？

WAFの補足

ファイアウォール・IPSとの違い

IPアドレスやポート等で通信を制御するファイアウォールに対し、WAFはWebアプリのHTTP内容に着目します。IPSにも内容検査等の機能があり、製品によって機能は重なります。「FWは中身を一切見ない」「IPSはWebを守れない」とは限りません。WAFは上位互換や万能な代替品ではなく、役割・配置・検査対象を分けて考えます。[T01]

ルール一致から遮断が決まるまで

主図は架空の検知条件と、この教材の拒否方針を使った単純化です。実際には複数の検知結果からスコアを合計し、閾値と比べる方式等があります。OWASP CRSの説明でも検知と遮断判断を分けています。教材の文字列を、実運用のSQL対策用ブラックリストとして使用しないでください。実製品の推奨閾値・現行版の設定値は指定していません。[T03]

HTTPSの検査と設置場所

暗号化されたままのHTTP内容を無条件に読める仕組みではありません。TLS終端後に検査するなど、内容にアクセスできる構成が必要です。WAFは専用装置だけでなく、サービスやサーバーに組み込まれた機能としても提供されます。この教材はTLS終端後の要求検査の図であり、すべての設置形態を再現するものではありません。[T01・T02]

導入後の確認と限界

WAFは通信内容を条件と照合します。検知を記録して通すか、アプリへの転送を止めるかは設定によって変わります。通過は安全の保証ではなく、遮断してもアプリの脆弱性そのものが直るわけではありません。[T01〜T04]

誤検知：正常な検索でも一致する

SQLの解説を探す人が、検索語に『OR 1=1 の意味』と入力した場合も、教材ルールAには一致します。正当な検索なら誤検知となり、遮断設定では利用を妨げます。[T04]

見逃し：一致しない不正利用もある

他人の注文を閲覧しようとする要求でも、この教材ルールの並びを含まない場合があります。一般的な攻撃パターンの照合だけで、その利用者に閲覧権限があるかまでは判断できません。[T01]

併用する対策：ルール運用とアプリの修正

検知ログと正常な利用への影響を確認し、ルールを更新・調整します。アプリ側でも、SQLへ渡す値をパラメータとして分離したり、要求ごとに権限を確認したりする対策が必要です。[T02・T05]

アプリ変更や新しい攻撃への対応に応じて、ログ・利用への影響を確認し、ルールや対象範囲を調整します。ログには機微な情報が入り得るため、記録内容・閲覧権限等も設計します。WAFを迂回してアプリへ直接到達できる構成も確認対象です。[T01・T02・T04]

要求を止める主例と、処理後の応答だけを止める構成は異なります。後者はアプリ側の処理が既に行われている場合があります。WAFによる被害の緩和と、アプリの根本対策を併用します。[T02・T03]

関連：SQLインジェクション

参考資料

RELATED CONCEPTS

関連Concept