WAFは、Webサーバの手前に立って要求の中身を読み、攻撃らしいものを止める装置・サービスです。名前が似ているファイアウォールとは見ている層が違います。ここを取り違えると「FWがあるのになぜWAFが要るのか」に答えられません。
先に押さえる
ファイアウォールは宛先と入口（アドレスとポート番号）で通す・通さないを決めます。ところがWebの攻撃は、通してよい入口（Webの窓口）から、通常の形の要求として入ってきます。宛先で見ている限り、正常な閲覧と区別が付きません。そこで要求の中身（パラメータや本文）まで読むのがWAFです。層が違うので、どちらかで代替できません。
止める場所が違う
ファイアウォール
- 見るもの：宛先・送信元・ポート番号
- 止めるもの：開けていない入口への接続
- Web宛の要求は中身を見ずに通す
WAF
- 見るもの：要求の中身（入力値・本文・ヘッダー）
- 止めるもの：注入や不正な操作を狙う要求の形
- 正常な閲覧は通し、攻撃らしいものだけ落とす
動きで見る
1要求はWAFを通ってからサーバへ届く
利用者・攻撃者同じ入口へ、同じ形の要求を送る
↓入力値に注入を狙う文字列が混ざっていないか
WAF中身を検査し、合致すれば遮断・記録するここで判定
↓通ったものだけが到達する
Webサーバ／アプリ本来の処理を行う
判定の作り方は2通りあります。攻撃の型を集めて「これに合ったら落とす」とするやり方（既知の手口に強く、未知に弱い）と、正常な形を定義して「それ以外を落とす」やり方（未知にも効くが、定義の手間が大きい）。実務では前者を土台に、必要な箇所で後者を足します。
つまずきポイント
WAFは暗号化されたままの通信の中身を読めません。読むには手前で一度ほどく必要があり、その分だけ「平文が見える場所」が増えます。また、止める判定を厳しくすると正常な利用まで落ち（誤検知）、緩めると攻撃が通り抜けます。導入後に何もしなくてよい装置ではなく、調整が前提です。
本命はアプリの修正、WAFは時間を買う手段
見抜きどころ
設問では、脆弱性が見つかった直後に「修正までの間どうするか」という形で出ます。答えの向きは暫定対策：アプリを直すには影響調査と試験の時間が要るので、その間だけWAFで該当の要求を止める。逆に「WAFを入れたから直さなくてよい」は誤りで、根本対策はアプリ側の修正です。この暫定と恒久の切り分けがそのまま得点になります。
置き方で変わること
手前に置く（経路上）
- 通信が必ず通るので漏れがない
- 止まるとサービスも止まるため冗長化が要る
サーバに同居させる
- 機器を増やさずに済む
- サーバの負荷を食う。台数分の設定が要る