Cloudflare、AIエージェントを用いて自社Webアプリケーションファイアウォールをストレステスト

Cloudflareのエンジニアは最近、最先端の大規模言語モデル（LLM）を使用して、自社のWebアプリケーションファイアウォール（WAF）に対する厳格なストレステストを実施しました。2026年9月29日に公開されたこの研究では、自動化システムが敵対的なハッカーとして機能し、リアルタイム防御の盲点を見つけるために数千ものペイロード変異を反復処理した方法が詳細に説明されています。実験により、難読化されたサーバーサイドリクエストフォージェリ（SSRF）やコマンドインジェクション試行の処理における特定の弱点が明らかになり、Cloudflareのマナルールセットへの即時アップデートにつながりました。

何が起きたか

セキュリティチームは、現代のAIモデルが従来の静的または動的解析ツールよりも効果的にWAF保護を回避できるかどうかを評価するために、カスタムのPythonベースのテストハーネスを構築しました。標準的なペネトレーションテストとは異なり、このシステムはLLMを使用して、ライブHTTPレスポンスに基づいて攻撃ベクトルを動的に変異させました。テスターはソースコードや内部WAFルールへのアクセス権を持っておらず、次の行動を導くために選択されたレスポンスデータのみを頼りにしていました。このブラックボックスアプローチは、外部攻撃者がそのインフラストラクチャに関する事前知識なしに保護されたアプリケーションを探る方法を模倣したものです。

テストは、Cloudflareの最も厳しい設定で構成された承認済みの顧客ステージング環境に対して実行されました。これには、30以下のWAF Attack Scoreによるブロックと、Paranoia Level 3でのOWASP Core Rulesetが含まれていました。実験期間中、システムはクロスサイトスクリプティング、SQLインジェクション、コマンドインジェクション、サーバーサイドリクエストフォージェリ、パストラバーサル、Log4jエクスプロイトという6つの主要な攻撃カテゴリーをカバーする45のシナリオで1,107回の変異試行を実行しました。ほとんどの攻撃はブロックされましたが、プロセスは人間のレビューとその後の緩和策を必要とする49件の具体的な発見事項を特定しました。

成功した回避の大部分は、コマンドインジェクションとサーバーサイドリクエストフォージェリの2つのカテゴリーに分類されました。例えば、あるSSRFシナリオでは、モデルはクラウドメタデータIPアドレスの末尾にドットを追加して表現することで、標準的な10進数または8進数の表現では失敗した検知を回避できることを発見しました。これらの発見は確認されたエクスプロイトではなく、WAFの正規化ロジックが特定の境界ケースを異なる方法で扱う可能性を示唆する手がかりでした。チームはこれらの洞察を利用して検知エンジンを改良し、難読化されたホストと制限付きプロトコルに対する新しいルールを作成しました。

仕組み

テストシステムは、各反復において2つの異なるLLM呼び出しによって駆動される適応ループで動作します。最初の呼び出しである提案フェーズでは、初期のリクエストコンテキストと以前の結果の履歴を受け取り、新しいバリエーションを提案します。エンコーディングの変更、ペイロードをHTTPリクエストの別の部分へ移動、または宛先形式の変更などが行われる可能性があります。2番目の呼び出しであるレビューフェーズでは、レスポンスステータス、ヘッダー、ボディを分析し、試行が成功したのかブロックされたのかを判断します。このフィードバックループにより、モデルは基礎となるWAFルール式や攻撃スコアを見ることなく、どの変異が有効かを学習できます。

重要なのは、コードが実行環境に対して厳格な制御を維持していることです。LLMはリクエストを直接送信しません。代わりに、Pythonハーネスが検証および実行する提案を生成します。各リクエストの前に、システムはターゲットホスト名を許可リストに対してチェックし、リダイレクトを無効にし、試行回数にハードリートを課します。各レスポンスの後、システムは構造化された証拠を記録し、返されたテキストを信頼できない入力として扱います。この設計により、テストプロセスが安全かつ再現可能な状態に保たれ、評価中にAIが意図しない損害を引き起こしたり機密データを漏洩させたりすることを防ぎます。

主要な詳細

• テストでは1,107回の変異試行が生成され、そのうち558回はアプリケーションに到達する前にWAFによって明示的にブロックされました。
• 人間のトリアージにより、生出力は49件の有効な発見事項に絞り込まれ、そのうち48件はコマンドインジェクションまたはSSRFに関連していました。
• WAF設定には、30以下のWAF Attack Scoreによるブロックと、Paranoia Level 3でのOWASP Core Rulesetが含まれていました。
• テスト後に、SSRF難読化ホストと制限付きプロトコルに対する新しい検知ルールがManaged Rulesetに追加されました。
• システムは各反復で2つの個別のLLM呼び出しを使用しました。1つは変異の提案用、もう1つはレスポンスのレビュー用です。
• WAFを回避したリクエストは調査のための手がかりとして扱われ、確認されたエクスプロイトではなく、さらなる検証が必要でした。

重要性

ソフトウェアエンジニアやセキュリティリーダーにとって、この研究は適応型の敵対者に対する静的なルールベース防御の限界を浮き彫りにしています。従来のペネトレーションテストはしば事前に定義されたスクリプトに従うため、AIが反復を通じて発見できるような新しいエンコーディング技術や論理的欠陥を見逃すことがあります。LLMが高度に設定されたWAFでさえギャップを発見できることを示すことで、Cloudflareは脅威ランドスケープとともに進化し続ける継続的で自動化的なセキュリティテストの必要性を強調しています。攻撃者が既知のエクスプロイトの無限の変異を生成するためにAIを使用できる場合、シグネチャーベースの検知だけに頼るのは不十分であることを示唆しています。

また、これらの発見は多層防御の重要性も強化しています。WAFが特定の変異リクエストをブロックできなかった場合でも、アプリケーション自体は安全でなければなりません。SSRFの例では、回避がデータ流出につながらなかったのは、アプリケーション層が独自のプロテクションを持っていたか、リクエストが実際の悪用を防ぐ形で不正だったためと考えられます。これは開発者に対し、ソフトウェアのパッチ適用と依存関係の最新化が、ネットワークレベルのセキュリティコントロールにとって重要な補完要素であることを思い出させます。WAFは盾であり特効薬ではなく、その有効性はスタック全体のレジリエンスに依存します。

実施できること

• すべての利用可能なマナルールセットを有効にし、リスクプロファイルに応じた推奨レベルにWAF Attack Score閾値を設定してください。
• 本番環境と同じWAF設定で保護されたステージング環境に対して、既存のアプリケーションセキュリティテストを実行してください。
• 予期されるリクエスト形状を定義するポジティブセキュリティコントロールを実装し、未知の変異に対する攻撃面を削減してください。
• 新しいルールを強制する前に、ログオンリーモードでセキュリティイベントを確認し、誤検知と正当なトラフィックパターンを特定してください。
• WAF層が失敗した場合に露呈する可能性のある脆弱性を軽減するため、アプリケーションの依存関係とフレームワークを最新の状態に保ってください。
• ペイロードの適応型変異に焦点を当て、手動ペネトレーションテストを補完するためにAI駆動型テストツールの使用を検討してください。