あらゆる pull request エンドポイントを追加または変更すると、APIの攻撃対象領域が変わります。ほとんどのAPIセキュリティツールは、そのエンドポイントが稼働してトラフィックを受け付けるようになるまで、その変更に気づきません。そうなると、修正はコードレビューでの1行の変更では済まず、インシデント対応の話し合いが必要になります。
APIセキュリティとは、アプリケーションがエンドポイントを公開する際のリスク(誰がエンドポイントを呼び出せるか、どのようなデータが返されるか、ドキュメントに記載されているとおりに動作するかなど)を特定し、解消するための取り組みです。
この問題に対処するために開発されたツールのほとんどは、攻撃者が行うのと同じように、実行時に外部からAPIをテストします。この方法は有効ですが、APIがデプロイされた後にしか機能しません。 ザイゲニ これは、より早い段階の手順を踏むものです。つまり、エンドポイントにリクエストが送信される前に、ソースコードとAPI仕様を読み込みます。
APIをテストする4つの方法と、それぞれの方法が示す内容
ほとんどの成熟したプログラムは、これらのうち複数を実行します。
- 静的テスト デプロイ前にソースコードとAPI仕様を分析し、「今回公開したものは何だったのか?」という問いに答えます。この記事では、このアプローチに焦点を当てます。
- 動的テスト(DAST) 実行中のAPIに実際のトラフィックを送信し、その応答を観察します。これにより、「現在、実際にアクセス可能で悪用可能なものは何か?」という問いに答えます。
- ファジング エンドポイントに不正な入力や予期しない入力を投げかけることで、クラッシュやエッジケースの障害を顕在化させます。「想定していなかった入力によって何が壊れるのか?」という問いに答えます。
- 手動浸透試験 自動化ツールが見逃す論理的な欠陥を見つけるために、人間の判断力を加える。「賢い攻撃者はどのような論理的連鎖を仕掛けるだろうか?」という問いに答える。
これらはどれも他のものに取って代わるものではありません。それぞれがライフサイクルの異なる段階で異なる疑問に答えるものであり、ほとんどのプログラムが抱えるギャップは最初の段階にあります。
ほとんどのAPIセキュリティツールがリスクを認識するのが遅すぎる理由
ランタイムAPIセキュリティテストでは、稼働中のアプリケーションにトラフィックを送信し、その応答を監視します。これは正当かつ必要なレイヤーです。しかし、その構造上、遅行指標となる側面もあります。ランタイムスキャナーがエンドポイントについて何らかの情報を得るには、エンドポイントが存在し、デプロイされ、アクセス可能である必要があります。スキャンが実行された時点で、検出された問題はすでに公開されていたことになります。
タイミングの問題の根底には、もう一つの問題点があります。ランタイムツールは、存在がわかっているものしかテストできません。エンドポイントが文書化されていなかったり、新しいルートがリリースされた瞬間にOpenAPI仕様が古くなったりした場合、ランタイムスキャナーはそれが存在することを知る術がありません。つまり、地図をテストするだけで、実際の領域をテストしているわけではないのです。
静的APIセキュリティテストは、エンドポイントが定義されている場所、つまりデプロイ前のコードとAPI仕様にチェックを移すことで、両方のギャップを解消します。 pull request エンドポイントを導入するのは pull request それはそのリスクを浮き彫りにする。
静的APIセキュリティの実際の意味
Xygeniは、アプリケーションのソースコードと、OpenAPIやSwaggerなどのAPI仕様という2つのソースからAPIインベントリを構築します。
仕様書のみのインベントリには、誰かが文書化することを覚えていたエンドポイントが表示されます。コードのみのインベントリには、存在するものは示されますが、必ずしもそれがどのように使用されることを意図しているかは示されません。両方を読むことで、チームが文書化したエンドポイントと、誰も文書化しなかったエンドポイントの両方を含む、全体像を把握できます。
その在庫こそが、他のすべてのものの土台となるものです。
- 発見されたAPIの総数と、基準値と比較したリスクのある資産
- HTTPメソッド別に分類されたエンドポイント
- サービス別にグループ化された問題
- メソッド、パス、サービス、モジュール、認証状態、リスクスコアを含むすべてのエンドポイント
エンジニアリングリーダーは、チケットを1枚も発行することなく、APIサーフェスの形状を把握できます。
Xygeniが発見したすべてのエンドポイントは、そのメソッド、認証状態、リスクスコアとともに、コードと仕様を組み合わせて構築されています。
Production note APIセキュリティのスクリーンショットから、AIトリアージパネルを切り抜きます。
OWASP APIセキュリティトップ10にマッピングされています
調査結果は、セキュリティチームと監査担当者が既に利用しているフレームワークを裏付けています。XygeniはOWASP APIセキュリティ全体にわたるリスクを検出します。 トップ10 (2023):
| OWASP | リスク | 実際に何を意味するのか |
|---|---|---|
API1 | 壊れたオブジェクトレベルの認証 | エンドポイントは、別のユーザーまたはテナントに属するデータを返すか、または変更します。 |
API2 | 認証されていないエンドポイント | 認証なしで到達可能なルート |
API3 | 過剰なデータ露出 | レスポンスは、呼び出し元が必要とする、または見るべき以上のフィールドを返します。 |
API3 | 大量割り当て | エンドポイントが、本来受け入れるはずのないフィールドを受け入れて適用する。 |
API3 / API10 | 回答に含まれる機密データ | PII、PCI、またはPHIが、送信すべきでないエンドポイントからクライアントに届く。 |
API4 | レート制限が欠落しています | エンドポイントには、不正利用やブルートフォース攻撃に対する保護機能がありません。 |
API5 | 機能レベル認証の不具合 | エンドポイントは、呼び出し元が許可されているかどうかを確認せずに特権アクションを実行します。 |
API7 | SSRF | APIは、攻撃者の意図に反してリクエストを送信するように悪用される可能性がある。 |
API8 | JWTの設定ミス | トークンの検証、署名、または有効期限の設定が正しくありません。 |
API8 | CORS設定ミス | クロスオリジンルールは悪用されるほど寛容である |
API9 | ゾンビエンドポイントと孤立エンドポイント | 廃止された、あるいは忘れ去られたルートで、まだアクセス可能なもの、および誰も所有していないルート |
意図的に除外されているカテゴリが1つあります。API6「機密性の高いビジネスフローへの無制限アクセス」では、ビジネスプロセスが何を許可するべきかを理解する必要があり、静的アナライザーではそれを確実に検出することはできません。そうでないと主張するベンダーは、単なるチェックボックスを売りつけているだけです。これは、脅威モデリングと侵入テスト担当者が担当すべき事項です。
すべての発見が同等とは限らない:データの感度と有害な組み合わせ
検出結果のリストを単純に表示した場合、認証されていないヘルスチェックエンドポイントと、認証されていないものの顧客レコードを返すエンドポイントを同じように扱います。これらは同じ問題ではないため、これらを同じように評価する優先順位付けモデルでは、チームがリストを無視するように学習してしまうことになります。
Xygeniは、各エンドポイントが処理するデータを分類し、リクエストパラメータとレスポンスに含まれるPII、PCI、PHIにフラグを付け、それをエンドポイントの認証状態と関連付けます。
また、同じエンドポイントで発生した複数の検出結果を関連付け、それらが複合的に発生すると深刻度を引き上げます。レスポンスにおける個人情報漏洩は、それ自体が重大な検出結果です。認証を必要としないエンドポイントで同じ漏洩が発生した場合は、重大な問題とみなされ、プラットフォームは手動で確認するのではなく、そのようにスコアリングします。
ゾンビエンドポイントと孤立エンドポイント:コードと仕様の間の乖離
XygeniはコードとAPI仕様を並べて読み込むため、両者の相違点を検出します。その相違は、以下の3つの特徴的なパターンとして現れます。
- 文書化されていないエンドポイント。 それらはコードの中に存在し、仕様書には追加されなかった。
- ゾンビエンドポイント。 それらは非推奨または廃止済みとしてマークされていますが、それでもアクセス可能です。
- 孤立したエンドポイント。 現在のチームメンバーで、それらを所有している人は誰もいません。
これらは仕様書のみのインベントリには表示されません。なぜなら、仕様書にはまさにそれらが欠けているからです。
行動に移せる証拠であって、捜査のきっかけではない
発見された脆弱性はすべて、原因となったハンドラ(ファイル、クラス、メソッド、脆弱性を導入した特定の行)を正確に示しており、問題のあるコードも併せて表示されます。また、それぞれの脆弱性には、深刻度、OWASP API Security Top 10のカテゴリ、CWE、エンドポイントの認証状態、および関連データの機密性分類も記載されています。
エンドポイント名だけを示す検出結果では、開発者は修正作業に取りかかる前にコードベース全体を探し回らなければならない。一方、該当行名を示す検出結果であれば、すぐに修正箇所にたどり着ける。
調査結果は JSON、CSV、Markdown、SARIF 2.1.0 としてエクスポートされるため、t に格納されます。チームが既に利用しているツール。
問題を引き起こしたハンドラー、行、およびコード。調査対象ではありません。
なぜこれが1つのプラットフォームにのみ存在し、他のコンソールには存在しないのか
XygeniはAPIセキュリティを以下の方法で実行します SAST, SCA, シークレットセキュリティ, IaC (NAIST) と ダスト 単一のプラットフォーム内で相関関係にある ASPM独自の別ツールとして出荷するのではなく login そして、自社の未処理案件も。
これは重要な点です。なぜなら、静的解析結果と実行時解析結果は、同じエンドポイントについて異なる疑問に答えるものであり、それぞれ単独で使用するよりも組み合わせて使用する方がはるかに有用だからです。静的解析結果は、エンドポイントが出荷される前にリスクがあることを知らせてくれます。DASTは、エンドポイントが実際に実行された後に、どこまで到達可能で悪用可能かを確認します。
それを2つのコンソールに分割すると、相関関係のあるリスクが2つの無関係なバックログになってしまう。誰もそれらを調整せず、文書化も認証もされていないエンドポイントはどちらのキューにも含まれない。
実際のAPI攻撃対象領域を確認しましょう。 APIセキュリティは Enterprise Xygeniプラットフォームのアドオンとして、自社インフラストラクチャ内の自社リポジトリに対してスキャンが実行されます。
FAQ
どのエンドポイントが機密データを扱っているかを判別できますか?
はい。Xygeniはエンドポイントのパラメータと応答においてPII、PCI、PHIを識別し、その分類に基づいて実際の曝露状況に応じて結果をランク付けします。
すべてのプラットフォームで動作しますか? pull request?
はい。増分スキャンは変更されたエンドポイントのみを分析し、生成されるマニフェストによって後続のDASTスキャンを同じエンドポイントに集中させることができるため、静的テストとランタイムテストは実際に変更された内容と常に一致した状態を維持できます。
私のコードは私の環境から外部に持ち出されますか?
いいえ。スキャンはお客様独自のインフラストラクチャ内で実行されます。結果のみがアップロードされ、転送中および保存中も保護されます。
APIセキュリティを取得するにはどうすればよいですか?
APIセキュリティは Enterprise アドオン。PoC(概念実証)をご依頼いただければ、お客様とご相談の上、実施範囲を決定いたします。





