記事を書き終え、下書きを保存しようとしたところ、画面に「403」。別の記事は保存できるのに、その原稿だけが受け付けられない。サイトを運営していると、こうしたトラブルに出会うことがあります。
その原因の一つが、サイトを守るWAFです。WAFはWebへの通信を検査し、攻撃と判断した通信を止めます。ただ、正常な投稿や問い合わせも攻撃に似た特徴を含み、止められることがあります。これが「誤検知」です。
本サイトの制作でも、下書き保存が拒否され、操作と防御記録の対応からWAFによる遮断が強く疑われたことがありました。どの記述が検知されたかまでは確定していません。設定は変更せず、その原稿の保存を見送りました。
WAFは何を見て、何から守っているのでしょうか。この記事では攻撃の仕組みから、誤検知が起こる理由、403が出たときの確認、マーケティングやサイト運営との関係までを整理します。
WAFとは？Webサイトへの通信の中身を検査する仕組み
WAFはWeb Application Firewallの略で、「ワフ」と読みます。Webアプリケーションとは、問い合わせフォーム、商品検索、会員ログイン、記事編集など、利用者の操作に応じて処理する仕組みです。WAFは、こうした機能へ届く通信を検査する防御機能です。[1][2]
例えば、商品検索欄に入れた言葉は、ブラウザーからサイトへ送られます。問い合わせ本文も、管理画面で保存する原稿も同様です。見た目は違っても、サーバーへ「この内容で処理してほしい」と依頼する通信である点は共通しています。この依頼をリクエストと呼びます。
WAFは、URLの指定や入力内容などをルールと照らし合わせます。通常の通信は先へ通し、攻撃の特徴がある通信には遮断などの処理を行います。サイトの手前で動くクラウド型も、サーバーに組み込む型もありますが、Webの処理を狙う通信を調べるという役割は共通です。
図は、リクエストを遮断する場合の概念図です。WAFが防御する場所を示しており、実際のサイト構成や設定を示すものではありません。
ファイアウォール・IDS・IPSとの違い
一般的なネットワークのファイアウォールは、通信元・通信先や通信に使うポートなどをもとに、通してよい通信を制御します。Webサイトを公開するには、閲覧に必要な通信を通さなければなりません。その通行を認めた通信の中に、攻撃のための入力が混じることがあります。
WAFは、そのWeb通信の内容へ踏み込んで検査します。「Webの入口を開くか」と「入口を通る依頼が危険ではないか」を分けると、役割をつかみやすくなります。
IDSは不正な通信を検知して知らせる仕組み、IPSは検知に加えて遮断する仕組みです。WAFは特にWebアプリケーションの通信を対象とします。製品には複数の機能をまとめたものもあるため、名称だけで守れる範囲を判断するより、対象の通信と検査内容を見るほうが実用的です。[1] ネットワーク側の防御機能をまとめた製品の例は、FortiGateの役割と機能でも紹介しています。
WAFの仕組み｜攻撃をどう見分けているのか
WAFは、送信者の意図を直接読んでいるわけではありません。通信に含まれる特徴や、あらかじめ決めた条件を使って判断しています。そのため、「本人が操作しているのだから通るはず」とは限りません。
攻撃の特徴と照合するシグネチャ方式
シグネチャとは、攻撃に特徴的な記述やパターンです。例えば、入力された文章の中にデータベースへの命令に似た構造がある、ファイルの位置を不自然にさかのぼる指定がある、といった特徴を検査します。
このように危険なパターンを定義する方式は、ブラックリスト型とも呼ばれます。一方、数値だけを受け付ける欄などで、正常な入力の形式を決め、外れるものを検出するホワイトリスト型もあります。自由な文章を書く欄では、正常な内容の幅が広いため、単純な形式制限だけでは扱いにくくなります。[1]
いずれも、設定とアプリケーションの使い方が合っていることが大切です。商品番号の入力欄と、記事本文の編集欄に同じ基準を当てはめると、後者で必要な表現まで止めてしまうことがあります。
複数の特徴を点数で評価する方式もある
一つのルールに一致しただけで直ちに遮断する方式のほか、複数の検出結果を点数にして、合計が基準に達したら遮断する方式もあります。
代表的なルールセットであるOWASP Core Rule Setは、検出した特徴を異常スコアとして積み上げ、しきい値と比較する仕組みを説明しています。したがって、ログにルールへの一致が一つ見つかったことと、そのルールだけで遮断が決まったことは同じではありません。[3]
また、検知内容を記録するモードと、実際に遮断するモードも区別されます。トラブルを調べるときは「何かが記録されている」だけでなく、その操作が本当に遮断されたかを見ることになります。
WAFで防御する主な攻撃｜SQLインジェクション・XSSなど
攻撃名は似ていますが、狙う処理や被害が違います。ここでは、商品検索・レビュー投稿・ファイル処理などを持つ架空のサイトを例に説明します。以下の攻撃が成立するのは、入力を処理するプログラムなどに、それを許してしまう弱点がある場合です。
SQLインジェクションとは？データベースを不正に操作する攻撃
SQLは、データベースへ情報の検索や更新を依頼するための言語です。SQLインジェクションは、利用者の入力を通じて、その命令の意味を不正に変える攻撃です。
商品検索なら、本来は「入力した商品名に合う商品を探す」という処理をします。ところが、入力文字列を命令文へそのままつなぐような作りになっていると、攻撃者の入力によって検索条件が書き換わることがあります。結果として、本来表示しない情報の読み出しや、データの変更・削除につながります。[4]
WAFは、SQLの攻撃に特徴的な構造を含むリクエストを検出して、データベースへ届く前の段階で止める役割を担います。ただし、入力を安全に扱うプログラムへ修正することも重要です。代表的な対策が、命令の構造と入力値を分ける「プレースホルダーを使ったパラメーター化」です。入力を命令ではなく、検索するデータとして扱うための仕組みです。
クロスサイトスクリプティング（XSS）とは？閲覧者のブラウザーを狙う攻撃
XSSは、サイトを通じて不正なスクリプトなどを送り、ページを開いた人のブラウザーで動かす攻撃です。スクリプトとは、ブラウザーなどに処理を実行させるプログラムです。
例えばレビュー欄の文章は、本来、文字として表示されれば十分です。しかし、入力された内容がプログラムとして解釈される作りだと、攻撃者の投稿を見た人の画面で不正な動作が起こります。情報の盗み取りや、利用者になりすました操作につながることがあります。[5]
SQLインジェクションがデータベースへの命令を変えるのに対し、XSSでは、サイトを信頼して開いた利用者側へ被害が広がる点が特徴です。自社サイトのデータだけを守ればよい、とはいえない理由でもあります。
WAFは不正なスクリプトに特徴的な入力の検出に役立ちます。アプリケーション側では、表示する場所に合ったエスケープ処理や、許可しないHTMLを除く処理などで、文章を実行可能なコードとして扱わないようにします。ブラウザー内の処理だけで起こるXSSもあり、WAFだけで全経路をカバーすることはできません。[5]
OSコマンドインジェクションとは？サーバー内部の処理を不正実行させる攻撃
OSコマンドは、サーバーの基本ソフトへファイル操作などを指示する命令です。OSコマンドインジェクションは、外部からの入力によって、本来予定していなかった命令を実行させる攻撃です。
例えば、受け取ったファイルを変換する機能が、内部で外部プログラムを呼び出す場面を考えます。ファイル名などの入力と命令の組み立て方に問題があると、変換とは無関係な処理を実行させられることがあります。実行権限によっては、ファイルの破壊や情報の持ち出しへ被害が広がります。[6]
WAFは命令を混入させる特徴を検査します。根本対策としては、外部のOSコマンドを直接呼ばずに処理できるライブラリーを使う、命令とデータを分離する、実行する権限を必要な範囲に絞る、といった設計が挙げられます。WAFは、サーバーのプログラム自体を書き換えて安全にする機能ではありません。
ディレクトリトラバーサルとは？非公開ファイルを読み出そうとする攻撃
ディレクトリはファイルを整理するフォルダー、トラバーサルは階層をたどることです。この攻撃では、ファイルの場所を指定する入力を操作し、本来アクセスできない範囲のファイルを読み出そうとします。
例えば、サイトから資料をダウンロードする機能があるとします。本来選べるのは公開資料だけなのに、指定した場所をそのまま読み込む作りだと、公開資料の範囲を外れて設定ファイルなどへ到達するおそれがあります。[7]
WAFは、ファイルの位置を不自然に指定するパターンなどを検査します。アプリケーション側では、利用者にファイルの場所を自由に指定させず、公開資料の番号から決まったファイルを選ぶ、アクセスできる範囲を制限する、といった対策が考えられます。
4つの攻撃に共通するのは、単なる入力のつもりで受け取ったものが、命令やアクセス先の変更として扱われることです。WAFで入口を検査しながら、受け取った側でも安全に処理する。この役割分担が防御の基本になります。
DDoS攻撃やブルートフォース攻撃はWAFで防げる？
WAFにアクセス回数の制限やボット対策の機能があれば、これらの攻撃への対策に使えます。ただし、DDoSとブルートフォースは目的が異なり、必要な対策も同じではありません。
DDoS攻撃｜大量の通信でサービスを使えなくする
DDoSは、複数の機器などから通信を送り、サービスを利用しにくくしたり、停止させたりする攻撃です。大量のページ要求でWebの処理能力を消費させる攻撃では、WAFのレート制限が役立ちます。レート制限とは、一定時間に受け付けるリクエスト数を制御する機能です。[8]
しかし、サイトへ届く回線自体を大量の通信で埋められる場合、サーバーの近くで処理を止めても、そこへ至る回線の混雑は解消できません。上流で通信を分散・吸収するDDoS対策も必要になります。「WAFにDDoS対策あり」という表示だけでなく、どの層の攻撃を、どこで処理するのかが確認点です。
また、アクセスの急増がすべて攻撃とは限りません。広告やテレビ紹介で正当なアクセスが集中することもあります。キャンペーンを計画する際は、サイトの処理能力とともに、正当な集中が防御設定で止まらないかも、運用担当者と確認すると役立ちます。
ブルートフォース攻撃｜パスワードを繰り返し試す
ブルートフォースは、パスワードの候補を繰り返し試して、ログインの突破を狙う攻撃です。大量のアクセスが生じる点はDDoSと似ていますが、主な目的はサービス停止ではなく、アカウントへの侵入です。[9]
WAFで短時間の大量試行を制限できても、接続元を分散したり、時間を空けたりする試行まで、同じ基準で見つけられるとは限りません。アプリケーション側でアカウントごとの失敗を管理することや、多要素認証を組み合わせることが有効です。[9]
多要素認証は、パスワードに加えて、本人が持つ端末など別の要素でも確認する仕組みです。入口の試行回数を抑えるWAFと、認証の強度を上げる仕組みでは、守り方が違います。
WAFの誤検知はなぜ起きる？正常な記事保存が止まる理由
誤検知は、正当な通信が攻撃の特徴に一致し、不正と判定されることで起こります。自由に文章やHTMLを入力できる編集画面は、通常の検索欄より多様な内容を送ります。WAFから見ると、正当な編集の一部が、攻撃に使われる記述と似ることがあります。
OWASP Core Rule Setの公式資料にも、WordPressへの正常なHTML投稿がXSSのルールに一致する例があります。アプリケーション側が許可されたHTMLを安全に扱っていても、手前の検査ルールがその事情をすべて把握しているとは限りません。[10]
このため、保存が止まったことだけで「原稿にウイルスが入っている」「不正な操作をした」とは判断できません。逆に、本人の入力だから安全として一律に通すことも、防御の目的に合いません。通信とルール、アプリケーションの処理を対応させて調べることになります。
誤検知と検知漏れは、反対方向の問題
正常な通信を止めるのが誤検知、攻撃を通してしまうのが検知漏れです。厳しく判定すれば正常な操作への影響が増える場合があり、判定を緩めれば防御できていた通信を通す場合があります。
だからこそ、調整の目的は単に「エラーを出さない」ことではありません。必要な操作を通しながら、攻撃への防御を保つことです。除外するなら、どの入力の、どの検査を、どこまで対象外にするのかで影響が変わります。[10]
WordPressで403・保存できないときの確認順
403は、サーバーが要求を理解したうえで、処理を拒否したことを示すHTTPステータスです。WAFによる遮断でも返りますが、それだけで原因を特定することはできません。WordPress自体も、リクエストの正当性を確認する値の検証に失敗した場合などに403を返します。[11]
最初に行うとよいのは、原稿を手元へ退避し、失敗した操作と保存状態を確かめることです。保存を何度も押すよりも、情報を残して調査へつなげるほうが、文章の消失や投稿の重複を避けやすくなります。
操作の失敗と、防御の記録を照合する
運用担当者へ伝える情報は、発生した時刻、どの操作で止まったか、表示されたエラー、他の操作が成功するか、です。担当者はそれをWAFやアプリケーションの記録と照合し、同じ操作に対して遮断が行われたかを確認します。
WAFの記録があれば、該当ルールや検知対象を調べます。一致する記録がなければ、権限、認証、アプリケーションやサーバー側の制限なども調査対象です。記録を公開する必要はなく、管理者や提供会社との適切な窓口で扱えば十分です。
冒頭の事例では、保存失敗と防御記録の対応からWAFを疑うところまでは進みました。しかし、どの文字列が原因かは確定していません。「この記号を消せば直る」という解決策を得た事例ではなく、原因を特定しきれず保存を見送った事例です。
WAFの無効化・除外は、対象と影響を見て判断する
サイト全体のWAFを無効にすると、問題の操作だけでなく、ほかの通信への検査も止まることがあります。一部のルールを外す場合も、そのルールが担っていた防御は変わります。「一つ外すだけだから安全性は変わらない」とは考えにくい理由です。
実際の対応は、誤検知の対象を絞り込んだうえで、入力処理の修正、ルールの調整などを運用担当者が検討します。正常な操作が通るかだけでなく、必要な防御を保てるかも確認することになります。[10]
原因が分からず、更新を急がないのであれば、原稿を保管して提供会社へ調査を依頼する選択もあります。問い合わせや購入が広く止まっているなら、影響範囲の把握と復旧の優先度を上げる。対応の緊急性は、止まった業務によって違います。
WAFをマーケティング担当者も知っておきたい理由
WAFはセキュリティ担当者だけの話ではありません。記事が保存できなければ情報発信が遅れ、問い合わせフォームが止まれば見込み客との接点を失います。広告から訪れた人が申し込めなければ、広告費が成果へつながりにくくなります。
例えば、フォームの送信完了が減ったとき、入力項目が多すぎるのか、広告と訴求が合っていないのかを考えることは自然です。そこへ「送信が技術的に拒否されていないか」という視点を加えると、調査の抜けを減らせます。分析画面の数字だけでは、拒否された場所や原因までは分かりません。
| 起きたこと | マーケティング・運営側で整理すること | 技術側と確認すること |
|---|---|---|
| 記事を保存できない | 原稿、発生時刻、影響する更新作業 | 保存状態、認証・権限、防御記録 |
| 問い合わせ完了が減った | 変化の時期、利用者の申告、直前のフォーム変更 | 送信エラー、遮断、アプリケーションの処理 |
| キャンペーン中にエラーが増えた | 集客開始時刻、流入の増え方、業務影響 | 処理能力、レート制限、攻撃の有無 |
この表は原因を決めつけるものではなく、担当者間で調査をつなぐための整理です。マーケターがルールの編集まで担う必要はありません。顧客の操作と事業への影響を具体的に伝えられることが、復旧や調整の助けになります。
WAFと多層防御｜入口の検査と、安全に処理する仕組みを組み合わせる
WAFを導入しても、アプリケーションの弱点自体が消えるわけではありません。入口での検査に加え、安全なプログラム、ソフトウェア更新、適切な権限、多要素認証などを組み合わせます。異なる場所で防御を重ねる考え方が多層防御です。更新や修正の順番を考える際は、脆弱性対応の優先順位も判断材料になります。
SQLインジェクションなら、WAFが攻撃らしい入力を止め、プログラム側でも入力を命令として扱わないようにする。ログインなら、大量試行を抑えつつ、パスワードだけで侵入されない認証を用意する。どちらも「一つの製品に任せる」より、各機能が何を担当するかを明確にした考え方です。
サイト運営では、防御の有無と、正常な利用者が使えることの両方が重要です。誤検知が起きたときも、まず操作と記録を結び付ければ、必要な防御を残しながら何を直すかを相談できます。WAFの役割を知ることは、その相談を具体的にするための基礎になります。
参考資料
- IPA「Web Application Firewall（WAF）読本」改訂第2版：WAFの位置づけ、検査方式、偽陽性・偽陰性、運用。PDFの第2〜4章、特にビューアー30〜31ページ（冊子28〜29ページ）。2011年の資料を基本概念に使用。
- OWASP「Web Application Firewall」：HTTP通信へルールを適用するWAFの定義と形態。
- OWASP CRS「Anomaly Scoring」：複数ルールの検出結果と遮断判定の関係。
- OWASP「SQL Injection Prevention Cheat Sheet」：SQLインジェクションとパラメーター化による対策。
- OWASP「Cross Site Scripting Prevention Cheat Sheet」：XSSの影響、出力処理、HTMLの安全な取り扱い。
- OWASP「OS Command Injection Defense Cheat Sheet」：OSコマンドインジェクションと安全な実装。
- OWASP「Path Traversal」：公開範囲外のファイル参照を狙う攻撃と対策。
- OWASP「Denial of Service Cheat Sheet」：アプリケーション・ネットワークへの攻撃、レート制限、上流での対策。
- OWASP「Authentication Cheat Sheet」：ブルートフォース対策、ログイン試行の制限、多要素認証。
- OWASP CRS「False Positives and Tuning」：正常なWordPress投稿の誤検知例、ルール調整。
- WordPress「rest_cookie_check_errors」：WAF以外でも403を返す認証確認処理。
本記事の文章・表・図解・グラフは、Skill Business Architecture Labが独自に編集・作成しています。引用・紹介する場合は、引用箇所が分かる形で、記事名・サイト名・記事URLをご記載ください。
コメント