Cloudflare、最先端AIモデルで自社WAFをテスト：大半の攻撃を遮断、発見が新たなSSRF検知ルールにつながる

何が起きたか：CloudflareがAIにハッカー役を担わせ自社ファイアウォールをテスト

Cloudflareは2026年9月29日、公式ブログにVikram Grover氏、Daniele Molteni氏、Kuber Nandwani氏による記事を公開した。Cloudflareによると、顧客から「御社のWAFは最先端AIモデルに対応できる準備ができているのか」とよく尋ねられるため、実際にテストすることにしたという。WAF（Webアプリケーションファイアウォール）とは、Webサイトの前段に置かれ、悪意あるリクエストをフィルタリングする防御層である。

Cloudflareは、大規模言語モデルがアプリケーションを攻撃する際の強みは、人間のハッカーより速く攻撃内容を繰り返し調整し、リアルタイムの応答に応じて手法を変えられる点にあると考えている。これを検証するため、Cloudflareは動的テストを採用した。動的テストとは、コードを読むのではなく、実際に動いているアプリケーションにリクエストを送って確かめる方法である。モデルはソースコードもWAFルールも見ることができず、HTTP応答データの一部だけを参照できる。Cloudflareは、遮断されなかったリクエストは人手のレビューに回す手がかりにすぎず、確認済みの脆弱性悪用ではないと強調している。

詳しい説明を読む

情報源を収集し、独立検証を行ってから Jev が判断します。

テストの方法：コードが管理するAIテストループ

Cloudflareによると、テスト対象は許可を得た顧客のステージング環境で、計45のシナリオを実行した。そのうち44シナリオは6種類の一般的な攻撃を対象としている。クロスサイトスクリプティング（XSS）、SQLインジェクション、コマンドインジェクション、サーバーサイドリクエストフォージェリ（SSRF：攻撃者の代わりにアプリケーションにデータを取りに行かせる攻撃）、パストラバーサルまたはローカルファイルインクルージョン（LFI）、そしてLog4jである。残る1シナリオはログインジェクションに関するもので、別途報告されている。

Cloudflareによると、テストシステムはPythonで実装され、各ループでモデルを2回呼び出す。1回は次のバリエーションを提案するため、もう1回は応答をレビューするためである。モデルは直接リクエストを送信せず、コード側が対象ホストが許可リストに含まれているかの確認、リダイレクトの無効化、各試行の記録、試行上限の適用を担う。モデルはルールの内容、ルールID、スコアの詳細を取得できず、ルールのデプロイや防御設定の変更もできない。

Cloudflareの説明によると、テストゾーンのWAF設定は次のとおり。WAF Attack Scoreで30点以下のリクエストをブロック、Cloudflare Managed Ruleset（Cloudflareが提供・管理する検知ルール群）を全面的に有効化、OWASP Core RulesetはParanoia Level 3を採用。Cloudflareは、結果は単一ルールの性能ではなく、設定全体の防御境界を反映したものだと指摘している。

結果：Cloudflareが公表した数字

Cloudflareは全体として良好な結果だったとし、XSS、LFI、SQLインジェクション、Log4jはほぼ完全にカバーされていたと述べている。集計に含まれなかった残りの試行は、モデルが有効なリクエストを生成しなかった、リクエストが対象に到達しなかった、あるいは生成された内容自体が無害だった、といった理由によるものだという。

Cloudflareはあるシナリオも例に挙げている。クラウドのメタデータサービスは一時的な認証情報を扱うことがあり、SSRFの脆弱性があると攻撃者がそれを取得できるおそれがある。このSSRFのシナリオで、モデルは同じクラウドメタデータアドレスをさまざまな形式で表現し、WAFはその大半を遮断した。唯一遮断されなかった1回では、リダイレクトが返されただけだった。Cloudflareは、アプリケーションが実際にメタデータを取得したという証拠はなく、さらに調査すべき手がかりにすぎないと明言している。

発見から防御へ：人手によるレビューと新ルール

Cloudflareによると、遮断されなかったリクエストはすべて、次の5つの問いによるレビューを経て初めて発見として数えられる。

1. テストツールは実際に有効なリクエストを送信したか？
2. リクエストは明確に遮断されなかったか？
3. 変化後のリクエストは依然として悪意あるものか？
4. この挙動はWAFで対処できる範囲に属するか？
5. エンジニアが安全に再現できるか？

Cloudflareによると、関連する発見は4つのグループのルール候補に分けられ、顧客トラフィックの保護に適用する前に実トラフィックでテストし、誤検知（正常なリクエストを攻撃と判定してしまうこと）のリスクを評価した。この取り組みにより、Managed Rulesetに3つの変更が加えられた。7月21日のリリースで「SSRF - Obfuscated Host」と「SSRF - Restricted Protocol」の検知が追加され、既存の「SSRF - Cloud」ルールが改善された。

一般の読者とサイト管理者にとっての意味

一般の読者にとって、この報告はAIモデルが「攻撃によって防御を試す」ために使われていることを示している。CloudflareはAIに大量のバリエーションを試させ、本当に修正に値するものを人間が判断した。Cloudflareの経験では、モデルはリクエストを生成するが、何が重要かを決めるのは人間であり、人手のレビューなしに本当の発見はないという。Cloudflareはまた、同じモデルファミリーの2つのバージョンは異なるバリエーションを生成したが、見つけた根本的な問題は同じだったとも述べている。

サイト管理者に向けたCloudflareの推奨の要点は、ソフトウェアを最新に保つこと（WAFを回避したリクエストが成功するには悪用可能なアプリケーションの脆弱性が必要なため）、そしてManaged RulesとWAF Attack Scoreが正しく設定されているか確認することだ。Cloudflareは顧客がこの実験を自ら再現する必要はないとし、まずManaged Rulesをログモードで実行し、Security Eventsで一致したリクエストを確認して、正常なトラフィックに影響がないことを確かめてからブロックに切り替えることを推奨している。

Cloudflareは今後、ホワイトボックステストの結果も共有する予定だとしている。その際、モデルはアプリケーションの脆弱性と、それを保護するWAFルールの両方を把握した状態でテストを行う。

このトピックの最新ニュースを見る

• テックニュース