Siembaは、API Security Testing機能の一部として、IDOR(安全でない直接オブジェクト参照)の自動テストを発表しました。この機能はREST、GraphQL、SOAPの各APIを対象に、顧客データの露出につながりやすい脆弱性クラスをテストします。
200エンドポイントのAPIコレクションであれば、1時間以内にIDORのテストを完了できます。従来であれば同等のカバレッジを人間のテスターが確保するには数日から数週間かかり、エンドポイントを1つずつ手作業で確認した上で、さらにその後数日かけて報告書を作成する必要がありました。Siembaはテストとレポート作成の両方を1回の継続的な実行に圧縮し、ソースコードを必要とせず、実際にデプロイされている状態のAPIに対して直接テストを行います。
IDORとは何か、なぜ重要なのか
IDORは認可に関する欠陥です。脆弱なエンドポイントは、呼び出し元が指定した識別子が本当にその呼び出し元のものであるかを確認しないため、リクエスト内の番号や識別子を1つ変更するだけで、他人のデータを閲覧したり改ざんしたりできてしまいます。OWASPはこれをBOLA(Broken Object Level Authorization)に分類しており、OWASP API Security Top 10の第1位にランクしています。
この脆弱性の悪用に高度な技術は必要ありません。概念自体は単純ですが、すべてのエンドポイントとパラメータについて漏れなく検証するのは非常に手間がかかるため、大規模環境では見落とされやすい脆弱性クラスの一つとなっています。また、実際のAPI侵害の公表事例において、最も繰り返し原因として挙げられている脆弱性の一つでもあります。
Siembaの最高セキュリティ責任者(CSO)を務めるSandhya Prashanth氏は次のように述べています。「APIの脆弱性の大半は、特殊なものではありません。あるユーザーのセッションが別のユーザーのデータを読み取れてしまう、それだけの話です。誰もチェックしていないから起きるのです。これがIDORであり、実際に起きているデータ侵害の大きな割合を占めています。発見するのにソースコードレベルの深い推論はほとんど必要なく、必要なのはすべてのエンドポイントを体系的にテストし続ける規律だけです。まさにこうした作業こそ、自動化が継続的に担うべきものであり、そうすることでセキュリティチームは、自動化では判断できない領域、つまり連鎖的な攻撃フローや権限境界の検証に注力できるようになります」
SiembaはどのようにIDORをテストするのか
テストは、チームがすでに管理しているAPI定義を起点に開始されます。OpenAPIまたはSwaggerファイル、Postmanコレクション、あるいはコレクションURLとして提供する形です。顧客側は識別子のセットを用意するだけでよく、認証済みセッションの処理はプラットフォーム側が担当します。Siembaは、ID風のパラメータを持つすべてのエンドポイントに対して、テストケースを作成・実行します。
それぞれの結果は、シグネチャやステータスコードの一致ではなく、実際のAPIレスポンスの内容を読み取って判定されます。空の結果や汎用的なエラーページを返す「200」は、合格とはみなされません。この点こそが、自動化された認可テストを信頼しにくいものにしてきた大量のノイズと、確証された検出結果とを分ける要素です。だからこそ、Siembaが返す検出結果はレポート作成フェーズを待つことなく、再現手順付きで最初から出力されます。
各プロトコルは、それぞれの仕様に沿ってテストされます。RESTエンドポイントは、パス・クエリ・ヘッダー・ボディの各パラメータについて個別にテストされます。GraphQLスキーマはイントロスペクション解析によって解決された上で、スキーマの露出、クエリの深さやバッチ処理の悪用、エイリアスのオーバーロード、フィールドレベルの認可についてテストされます。SOAP操作はWSDLから解析され、XML外部エンティティインジェクション、署名のラッピング、SOAPActionの改ざん、WS-Securityの設定不備についてテストされます。
自動化がカバーする範囲と、カバーしない範囲
確証された検出結果は、OWASP API Security Top 10の10カテゴリのうち9カテゴリに自動的にマッピングされます。残る1つであるBFLA(Broken Function Level Authorization、機能レベル認可の不備)に加え、連鎖的な攻撃経路や微妙な権限境界のテストについては、同一プラットフォーム上で作業するSiembaの有資格ペネトレーションテスターが担当します。そのため、専門家主導の診断は、ゼロから偵察を始めるのではなく、既知のベースラインを起点に開始できるようになり、診断予算のより多くを、人間にしかできない作業に充てられるようになります。
実務上の違いは、カバレッジと継続性にあります。時間に追われるテスターは、エンドポイントを抽出してサンプル的に確認するしかありません。一方、自動化はすべてのエンドポイントについて、あらゆる位置にあるID風パラメータをすべてテストします。また、特定時点で行う診断は、実施したその日のAPIを証明するにすぎず、それ以降にリリースされたすべてのエンドポイントは、次の診断まで未検証のまま残ってしまいます。継続的なテストは、この空白期間を埋めるものです。
本番環境での稼働を前提に設計
顧客は、4種類のスロットルプリセットを通じてテストのペースを制御できます。業務時間帯に適したステルスモードから、専用のテスト時間帯向けのターボモードまで用意されており、秒間リクエスト数、同時実行テストケース数、リクエストのタイムアウトをそれぞれ独立して制御できます。最大30日間のフリーズウィンドウを設定すれば、本番環境のフリーズ期間、取引のピーク時、重要なリリース時期などに合わせて、手動でのチケット申請なしにテストを自動的に一時停止できます。
これらの制御機能をあわせることで、IDORテストはデータと認可ロジックが実在する本番環境に対して実行できるようになり、本番環境から乖離してしまったステージング環境を対象にする必要がなくなります。
翻訳元: https://www.helpnetsecurity.com/2026/09/21/siemba-idor-automated-testing/
