はじめに
皆さん、こんにちは。本記事では、CloudflareのWAF機能導入について、WAFによる攻撃からの防御の検証も交えながら、導入手順を紹介していこうと思います。
前編となる本記事では、Cloudflare WAFの紹介、作成した架空の脆弱なECサイトを対象とした、WAFの有効化およびFreeプランでのWAFルールセットの作成・攻撃防御の確認までをご紹介します。
※本記事の内容は2026年4月現在の情報です。Cloudflareの更新により、UI・機能等が変更される可能性があります。
CloudflareのWAF機能(Cloudflare WAF)とは？
Webサイトや API への受信リクエストを検査し、ルールセットに基づいて不審なトラフィックをフィルタリングするセキュリティ機能です。Cloudflare のグローバルネットワーク上で動作するため、リクエストがオリジンサーバーに届く前に検査・遮断することができます。
ルールセットの設定は、Cloudflareトップページから、ドメイン > 対象ドメインをクリックし、セキュリティ > セキュリティルールより行うことが出来ます。
導入するには
Cloudflare WAFの導入には、防御したいサイトをCloudflareに追加し、CloudflareをサイトのリバースプロキシおよびDNSプロバイダーとして機能させる必要があります。
ドメインにオンボード ·Cloudflare Fundamentals ドキュメント
前提・環境
- Cloudflare アカウント（Free プラン以上）
- 防御対象のサイトのドメイン
Free プランの Cloudflare WAF について
Free プランでは、WAFのルールセットとして「Cloudflare Free Managed Ruleset（デフォルト設定・編集不可）」と「カスタムルール（5件まで）」が利用できます。
上位プランでは、「管理ルール」や「レート制限ルール」の設定が可能になります。
本記事では、カスタムルールを設定することで、攻撃がCloudflare WAFに設定したルールにより防御されることを検証するため、Freeプランを使用しています。
FreeプランのCloudflare WAFのみでWebサイトを防御する構成は、Freeプランの機能制限が大きいことから現実的ではないため、
実際の運用でより高度なWAF機能を利用したい場合は、上位プランの利用をご検討ください。
今回のデモサイト構成
検証用デモサイトには、OWASP Juice Shopをデプロイし、使用しました。
OWASP Juice Shopは、OWASPが主にセキュリティトレーニング用に公開している、悪用可能な脆弱性が意図的に複数仕込まれているウェブアプリケーションです。
本記事ではこのアプリケーションをデプロイし、脆弱性のある仮想のWebサイトとして見立てることで、CloudflareのWAF機能の使用によりWebサイトへの攻撃がブロックされる時の挙動を確認します。
攻撃検証
１.デモサイトに攻撃を行う
まずは、WAF機能導入前のWebページに、どのような攻撃が行えてしまうかを確認します。
ここでは、代表的な攻撃である、SQLi(SQLインジェクション)と、XSS(クロスサイトスクリプティング)を試してみます。
まず、SQLiを試します。
サイトのログイン画面のEmail入力欄に、「’ or 1=1 —」 を記入します。
これは、Emailの正誤判定およびパスワードのチェックを無効化することで、ログイン処理を突破する攻撃です。
このままLoginを押して、ログインを試行してみます。
Email,パスワードが不正なものであるにもかかわらず、ログインすることが出来てしまいました。
次に、XSSを試します。
サイト内の、注文履歴のページを開いてみます。
サイトを見ると、URL内のクエリがそのままHTMLに出力されているようです。（今回だと、?id=以降の、5267・・・から始まるid）
このクエリを、 <iframe src="javascript:alert(`xss`)">というスクリプトに書き換え、ページを更新してみます。
クエリの内容がHTMLにそのまま出力されることで、ブラウザがスクリプトをそのまま実行してしまい、ブラウザ上でアラートが表示されてしまいました。
このように、デモサイトは非常に脆弱な作りとなっており、未対策だと多くの攻撃が可能となっています。
2.Webサイト(アプリケーション)の追加
続いてCloudflareにデモサイトを追加し、WAF適用の準備を行います。 Cloudflare WAFは、ドメインをCloudflareに登録した上で、アプリケーションへのトラフィックをCloudflareのリバースプロキシ経由で通すことで機能します。
アプリへのトラフィックをリバースプロキシ経由で通すには、CloudflareのDNSゾーンにレコードを登録し、DNSプロキシを有効化します。（一般的には、ネームサーバーをCloudflareに変更するFull Setupで行います。）
Cloudflareがオリジンサーバーへのアクセス前に通信を受けることで、WAF等を提供します。
また、アプリケーションの公開にCloudflare Tunnelを利用する場合、ダッシュボードでの設定時にDNSレコードを追加するため、Tunnelでのアプリケーションの公開によって、WAFの保護を受けることが可能です。
- Cloudflare Tunnelでは、オリジンサーバー上で
cloudflaredを実行して、CloudflareとオリジンサーバーをアウトバウンドTunnel経由で接続を確立し、パブリックホスト名を設定することでアプリを外部に公開します。この設定の際に、プロキシが有効なCNAMEレコードをCloudflareのDNSゾーンに作成するため、アプリケーションへのトラフィックがCloudflareを経由し、WAF等のセキュリティ保護を受けることが出来ます。
DNSレコードを確認した際、プロキシステータス欄にオレンジ色の雲が表示されていれば、サイトへのトラフィックにCloudflareが経由されるため、WAFの適用準備が完了している状態です。 （Freeプランの場合は、デフォルトの管理ルールが自動で適用されます。）
DNSレコードは、アカウントトップページから、Domains > Overview > 対象のドメイン名 をクリック > DNS > レコードから確認できます。
3.カスタムルールの設定
前項で、デモサイトにCloudflare WAFによる防御ができるよう設定しました。
Cloudflare WAFでは、デフォルトのWAFルールセットが用意されており、WAFが有効になった時点でこのルールセットに基づいた防御が適用されます。
ただしFreeプランでデフォルトで設定されているルールは、Log4jやReact RCEなどの、重大度の高い脆弱性への対応に限られています。
そのため、サイトへの攻撃を防ぐには、カスタムルールの設定が必要となります。
※今回はルールセット作成から、WAFによる防御までの流れを検証するため、Freeプランを使用しています。Freeプランは機能・運用上の制約が多いため、より高機能なWAF機能をご利用したい場合は、上位プランの契約をご検討ください。
ドメインの管理から保護したいドメインの管理ページに移動し、セキュリティ> セキュリティルールを開きます。
ルールを作成からカスタムルールを選択し、新しいカスタムルールを作成します。
ルールの設定では、ルール名、受信リクエスト条件、条件に一致した場合のアクションを設定することが出来ます。
受信リクエスト条件では、フィールド欄から、URIやCookie、アクセス元の国などを指定することが出来ます。
また、設定する値の記述方法も、オペレーター欄から、ワイルドカード、完全一致、正規表現といった複数の記述方法から指定し、記入することが出来ます。
条件はAND,ORで複数組み合わせることも出来ます。
今回はURLからのXSS攻撃をブロックするルールを設定するため、URIに<iframeが含まれるリクエストをブロックするルールを指定します。
注：%3Cは、<記号のエンコードです。
ページ右下のデプロイを押すことで、設定したルールの適用が完了されます。
では設定後に、1.と同様にクエリを書き換えるXSS攻撃をサイトに仕掛けてみます。
XSS攻撃のURLリクエストがブロックされたため、WAFルール設定前とは違い、ブラウザ上でアラートが出現していないことが分かります。
セキュリティルールでも、イベント数が1になっており、設定したルールによるブロックイベントが起きたことが確認できます。
イベント検出のグラフ部分をクリックすることで、そのルールがブロックした通信の詳細ログも確認することが出来ます。(セキュリティ > Analyticsのページに遷移しています)
アクセス元の国や、URL情報、リクエストメソッドなどを確認できます。
おわりに
本記事では、WAF機能の紹介、およびWAF機能の導入・カスタムルールの設定によるXSS攻撃のブロックを検証しました。
しかし今回検証に使用したFreeプランは、デフォルトで有効になっているルールで防御できる攻撃が少ないほか、ルールの設定個数や条件・アクションの制限や、詳細なログ機能が使えないなど一部機能が制限されています。
後編では、Enterpriseプランを利用し、上位プランで設定されるWAFルールセットや、WAF導入のベストプラクティスについて紹介します。
