アクティブ防御：ステートフルなAPI脆弱性スキャナーの導入 | Cloudflare

claudejamodel: claude-sonnet-4-20250514

アクティブディフェンス：API向けステートフル脆弱性スキャナーの紹介

2026-03-09 | John Cosgrove, Alex Povel, Malte Reddig | 8分で読める

セキュリティは伝統的に守備のゲームです。壁を築き、ゲートを設置し、疑わしく見えるトラフィックをブロックするルールを作成します。長年にわたり、Cloudflareはこの分野のリーダーでした。当社のApplication Securityプラットフォームは、攻撃を飛行中にキャッチし、悪意のあるリクエストがオリジンに到達する前にエッジで削除するよう設計されています。

しかし、APIセキュリティにおいては、守備的な姿勢だけでは十分ではありません。そのため本日、CloudflareのWeb and API Vulnerability Scannerのベータ版をローンチします。まず、OWASP API Top 10で最も蔓延し、検出が困難な脅威である**Broken Object Level Authorization（BOLA）**から開始します。今後、APIとWebアプリケーションの両方の脅威を含む、より多くの脆弱性スキャンタイプを追加していく予定です。

今日最も危険なAPI脆弱性は、WAFが簡単に発見できる一般的なインジェクション攻撃や不正な形式のリクエストではありません。それらは論理的な欠陥です—プロトコルとアプリケーション仕様を満たしているが、ビジネスロジックに反する完全に有効なHTTPリクエストです。これらを見つけるには、攻撃を待つだけでは不十分です。積極的に探し出す必要があります。

Web and API Vulnerability Scannerは、まずAPI Shieldのお客様向けに提供されます。この最初のリリースでAPIセキュリティスキャンに焦点を当てる理由について、詳しく説明します。

純粋に守備的なセキュリティが的を外す理由

Webアプリケーションの世界では、脆弱性はしばしば構文エラーのように見えます。SQLインジェクション攻撃は、データがあるべき場所にコードがあるように見えます。クロスサイトスクリプティング（XSS）攻撃は、フォームフィールドにスクリプトタグがあるように見えます。これらには署名があります。

API脆弱性は異なります。説明のため、バックエンドのAPIとのみ通信するフードデリバリーモバイルアプリを想像してみましょう。注文エンドポイントを見てみましょう：

エンドポイント定義：/api/v1/orders

メソッド	リソースパス	説明
GET	/api/v1/orders/{order_id}	ステータス確認。特定の注文の追跡ステータスを返す（例：「キッチンで準備中」）
PATCH	/api/v1/orders/{order_id}	注文更新。ユーザーが配送場所を変更したり、配送指示を追加したりできる

BOLAのような認証破綻攻撃では、ユーザーA（攻撃者）がユーザーB（被害者）に属する有料注文の配送先住所の更新を要求します。攻撃者は単純にPATCHリクエストにユーザーBの{order_id}を挿入します。

以下が、ユーザーBの注文ID「8821」を使用したリクエストの例です。ユーザーAが自身の有効なトークンで完全に認証されていることに注意してください：

PATCH /api/v1/orders/8821 HTTP/1.1
Host: api.example.com
Authorization: Bearer <User_A_Valid_Token>
Content-Type: application/json

{
  "delivery_address": "123 Attacker Way, Apt 4",
  "instructions": "Leave at front door, ring bell"
}

リクエストヘッダーは有効です。認証トークンは有効です。スキーマは正しいです。標準的なWAFにとって、このリクエストは完璧に見えます。人間が手動で攻撃リクエストを送信している場合、ボット管理ソリューションでさえ騙される可能性があります。

ユーザーAは今、Bの食べ物を自分に配送してもらうことになります！

脆弱性が存在するのは、APIエンドポイントがユーザーAが実際にユーザーBのデータを表示または更新する権限を持っているかどうかを検証しないためです。これは構文ではなく、論理の失敗です。

これを修正するために、API開発者は簡単なチェックを実装できます：

if (order.userID != user.ID) throw Unauthorized;

アクティブなAPIテストトラフィックの送信または既存のAPIトラフィックの受動的リスニング

これらのタイプの脆弱性は、アクティブなAPIテストトラフィックの送信または既存のAPIトラフィックの受動的リスニングによって検出できます。受動的スキャンを通じてこれらの脆弱性を見つけるには、コンテキストが必要です。

昨年、API Shield向けのBOLA脆弱性検出をローンチしました。この検出は、使用異常についてお客様のトラフィックを受動的にスキャンすることで、これらの脆弱性を自動的に発見します。

このタイプのスキャンを成功させるには、以下を知る必要があります：

「有効な」API呼び出しがどのように見えるか
可変パラメータは何か
典型的なユーザーがどのように動作するか
これらのパラメータが操作されたときにAPIがどのように動作するか

しかし、API ShieldのBOLA脆弱性検出にアクセスできても、セキュリティチームがそのようなコンテキストを持たない理由があります：

開発環境はテストが必要だが、ユーザートラフィックが不足している場合がある
本番環境は（ありがたいことに）攻撃トラフィックが不足しているが、それでも分析が必要な場合がある

このような状況で、そして一般的に積極的になるために、チームはDynamic Application Security Testing（DAST）に頼ることができます。

従来のDASTツールの課題

セキュリティテスト専用に設計された新しいトラフィックプロファイルを作成することで、DASTツールはいつでもどの環境でも脆弱性を探すことができます。

残念ながら、従来のDASTツールには高い参入障壁があります：

設定が困難であることが多い
Swagger/OpenAPIファイルを手動でアップロードし、維持する必要がある
現代の複雑なログインフローに対して正しく認証するのに苦労する
API固有のセキュリティテスト（例：BOLA）が単純に不足している場合がある

CloudflareのAPIスキャンの優位性

上記のフードデリバリー注文の例では、攻撃者が変更する有効な注文を見つけることができると仮定しました。ライブ本番環境では攻撃者がこのタイプのインテリジェンスを収集する手段がしばしばありますが、セキュリティテストの演習では、APIの認証制御をテストする前に独自のオブジェクトを作成する必要があります。

典型的なDASTスキャンでは、多くのスキャナーが各個別のリクエストを独立して扱うため、これが問題になる可能性があります。この方法は、認証破綻脆弱性を見つけるために必要な論理的パターンでリクエストを連鎖させることに失敗します。

レガシーDASTスキャナーは、セキュリティツールとオーケストレーション環境内で孤立して存在することもあり、その発見をコンテキスト内で共有または表示することを妨げます。

Cloudflareの脆弱性スキャンは、いくつかの重要な理由で異なります：

1. 統合されたセキュリティインサイト

Security Insightsは、追加のコンテキストのために、既存のCloudflareセキュリティ発見と並んで新しいスキャンの結果をリストします。すべての姿勢管理情報を一箇所で確認できます。

2. APIの入出力の理解

API Shieldのお客様の場合、CloudflareはすでにあなたのAPIを理解しています。当社のAPI DiscoveryとSchema Learning機能は、エンドポイントを受動的にカタログ化し、トラフィックパターンを学習します。初回リリースではOpenAPI仕様を手動でアップロードする必要がありますが、将来のリリースでは仕様なしでも迅速に開始できるようになります。

3. エッジでの受動的トラフィック検査

エッジに位置するため、受動的トラフィック検査の知識をアクティブなインテリジェンスに変換できます。脆弱性スキャナーで新しいHTTPリクエストを送信することで、BOLA脆弱性検出リスク（トラフィック検査で発見）を簡単に検証できます。

4. 新しいステートフルDASTプラットフォーム

以下で詳しく説明するように、新しいステートフルDASTプラットフォームを構築しました。

ほとんどのスキャナーは、ツールにAPIとの通信方法を「教える」ために数時間の設定が必要です。Cloudflareでは、そのステップを効果的にスキップして迅速に開始できます。API認証情報を提供すれば、APIスキーマを使用してスキャンプランを自動的に構築します。

自動スキャンプランの構築

APIは一般的にOpenAPIスキーマを使用して文書化されます。これらのスキーマは、ホスト、メソッド、パス（一般的に「エンドポイント」）と、受信リクエストの期待されるパラメータと結果の応答を示します。

自動的にスキャンプランを構築するために、スキャンされる任意のAPIについて、これらのAPI仕様を最初に理解する必要があります。

当社のスキャナーは、OpenAPIドキュメントからAPI呼び出しグラフを構築し、その後攻撃者と所有者のコンテキストを使用してそれを歩くことで動作します。所有者がリソースを作成し、攻撃者がその後それらにアクセスしようとします。攻撃者は自身の有効な認証情報セットで完全に認証されています。攻撃者が所有していないリソースの読み取り、変更、または削除に成功した場合、認証脆弱性が発見されます。

API呼び出しグラフのモデリング

例えば、ID 8821の上記の配送注文を考えてみましょう。サーバーサイドリソースが存在するためには、最初に所有者によって作成される必要があり、おそらく依存関係がない、または最小限の「創世記」POSTリクエストで作成されます。APIを呼び出しグラフとしてモデリングすると、そのようなエンドポイントは受信エッジ（依存関係）がない、またはほとんどないノードを構成します。

攻撃者の上記のPATCHなどの後続のリクエストは、創世記リクエスト（POST）に対するデータ依存関係（データはorder_id）を持ちます。すべてのデータが提供されなければ、PATCHは進行できません。

紫色の矢印で、POST /api/v1/orders/{order_id}/note/{note_id}エンドポイント経由で注文にメモを追加するために訪問する必要があるこのAPIグラフのノードを示しています。

重要なことに、図に示されているステップやロジックのいずれもOpenAPI仕様では利用できません！他の手段を通じて論理的に推論される必要があり、それがまさに当社の脆弱性スキャナーが自動的に行うことです。

データ品質と曖昧な命名スキームの課題

様々なAPIにわたって信頼性があり自動的にスキャンを計画するために、これらのエンドポイント関係をゼロから正確にモデリングする必要があります。しかし、2つの問題が発生します：

API仕様のデータ品質は保証されない
機能的に完全なスキーマでも曖昧な命名スキームを持つ可能性がある

Workers AIを活用したソリューション

当社のスキャナーは、この曖昧な問題空間に取り組むためにCloudflare独自のWorkers AIプラットフォームを使用します。OpenAIのオープンウェイトgpt-oss-120bなどのモデルは、データ依存関係を確実にマッチングし、必要に応じて現実的な偽データを生成するのに十分強力で、本質的にOpenAPI仕様の空白を埋めます。

構造化出力を活用して、モデルは当社のスキャナーが歩くためのAPI呼び出しグラフの表現を生成し、攻撃者と所有者の認証情報を適切に注入します。

このアプローチは、OpenAPIスキーマの認証とデータ関係を推論するために人間の知能が必要な問題を、同じことを行う人工知能で解決します。構造化出力は、gpt-ossの自然言語世界から機械実行可能な指示への橋渡しをします。

Workers AIが計画問題を解決することに加えて、Workers AIでのセルフホスティングは、当社のシステムがCloudflareの高可用性でグローバルに分散されたアーキテクチャから自動的に恩恵を受けることを意味します。

実証済みの基盤の上に構築

お客様がAPI認証情報を信頼する脆弱性スキャナーを構築するには、実証済みのインフラストラクチャが必要です。ここで車輪の再発明はしませんでした。代わりに、スキャナープラットフォームの2つの重要なコンポーネントについて、Cloudflare全体で検証され展開されているサービスを統合しました：スキャナーのコントロールプレーンとスキャナーのシークレットストア。

スキャナーのコントロールプレーン

スキャナーのコントロールプレーンは、スキャンオーケストレーション用にTemporalと統合されており、Cloudflareの他の内部サービスもすでにこれに依存しています。各スキャンで実行される多数のテストプランの複雑さは、Temporalの耐久実行フレームワークによって効果的に管理されます。

バックエンドアーキテクチャ

バックエンド全体はRustで書かれており、これはインフラストラクチャサービス用にCloudflareで広く採用されています。これにより、内部ライブラリを再利用できます。

Active defense: introducing a stateful vulnerability scanner for APIs

要約

Summary

Key Points

翻訳