OWASP『API Security Top 10 2023』について調べてみた

参考文献
APIセキュリティとは?
API Security Top 10 2023のTop10の詳細

OWASP『API Security Top 10 2023』について自分で調べた際の、個人の解釈のまとめです。出典元の正確な内容は以下のリンク先より確認してください。

参考文献

OWASP API Security Project | OWASP Foundation

APIセキュリティとは?

以下、OWASPの本文からの引用です。

A foundational element of innovation in today’s app-driven world is the API. From banks, retail and transportation to IoT, autonomous vehicles and smart cities, APIs are a critical part of modern mobile, SaaS and web applications and can be found in customer-facing, partner-facing and internal applications. By nature, APIs expose application logic and sensitive data such as Personally Identifiable Information (PII) and because of this have increasingly become a target for attackers. Without secure APIs, rapid innovation would be impossible.

API Security focuses on strategies and solutions to understand and mitigate the unique vulnerabilities and security risks of Application Programming Interfaces (APIs).

「『APIが攻撃者の標的になることが増えている』という状況下で、APIに特有の脆弱性とセキュリティリスクを理解し、軽減するための戦略とソリューションに焦点を当てた啓蒙ドキュメント」ととらえてよいと思います。そしてドキュメントの内容は最新のサイバー攻撃を分析した結果ですので内容を理解し、対策を行うことがWeb上の安全の確保に役立つと考えられます。

API Security Top 10 2023のTop10の詳細

API1:2023 - Broken Object Level Authorization

オブジェクト毎に適切な認証がされていない

説明

Object Level Authorizationは、ユーザーがアクセス許可をもつオブジェクトのみにアクセスできることを検証する処理で、コードレベルで実装されるアクセス制御メカニズム。
オブジェクトのIDを受け取り、オブジェクトに対してアクションを実行するすべてのAPIエンドポイントは、オブジェクトレベルの認可チェックを実装する必要がある。
- このチェックでは、ログインしたユーザーが、要求されたオブジェクトに対して要求されたアクションを実行する権限を持っているかどうかを検証する必要がある。
通常、このメカニズムに障害が発生すると、すべてのデータが不正に情報開示、変更、または破壊される。
現在のセッションのユーザーIDを(JWTトークンから抽出するなどして)脆弱なIDパラメーターと比較することは、BrokenObjectLevelAuthorization(BOLA)を解決するのに十分な解決策ではない。
- このアプローチでは、少数のケースのみに対処できる。
BOLAの場合、ユーザーが脆弱なAPIエンドポイント/関数にアクセスできるように設計される。
- IDを操作することにより、違反はオブジェクトレベルで発生する。
- 攻撃者がアクセスすべきではないAPIエンドポイント/関数にアクセスできた場合、これはBOLAではなく機能レベル認証(BFLA)のケース。

脅威エージェント/攻撃ベクトル

API 固有/悪用が簡単

詳細

  - 攻撃者は、リクエスト内で送信されるオブジェクトのIDを操作することにより、オブジェクトレベルの認証の破損に対して脆弱なAPIエンドポイントを悪用する可能性がある。
  - オブジェクトIDには、連続する整数、UUID、または汎用文字列を使用できる。
  - データ型に関係なく、リクエストターゲット(パスまたはクエリ文字列パラメータ)、リクエストヘッダー、さらにはリクエストペイロードの一部で簡単に識別できる。

影響

技術的中程度 : ビジネス固有

詳細

  - 他のユーザーのオブジェクトに不正にアクセスすると、不正な関係者へのデータ漏洩、データ損失、またはデータ操作が発生する可能性がある。
  - 特定の状況下では、オブジェクトへの不正アクセスが完全なアカウント乗っ取りにつながる可能性もある。

予防方法

ユーザーポリシーと階層に依存する適切な承認メカニズムを実装する。
認可メカニズムを使用して、クライアントからの入力を使用してデータベース内のレコードにアクセスするすべての関数で、ログインしたユーザーがレコードに対して要求されたアクションを実行するためのアクセス権を持っているかどうかを確認する。
レコードのIDのGUIDとしては、ランダムで予測不可能な値を使用する。
認可メカニズムの脆弱性を評価するテストを作成する。テストが失敗するような変更をデプロイしない。

API2:2023 - Broken Authentication

認証機能の欠陥

説明

認証エンドポイントとフローは、保護する必要がある。
さらに、「パスワードを忘れた場合/パスワードをリセットした場合」は、認証メカニズムと同じように扱う必要がある。
次の場合は脆弱です
- 攻撃者が有効なユーザー名とパスワードのリストを使用してブルートフォースを使用するクレデンシャルスタッフィングを許容する。
- 攻撃者がキャプチャ/アカウントロックアウトメカニズムを提示せずに、同じユーザーアカウントに対してブルートフォース攻撃を実行することを許容する。
- 弱いパスワードを許容する。
- URL内の認証トークンやパスワードなどの機密認証の詳細を送信する。
- ユーザーに対し、パスワードの確認を求めずに、電子メールアドレス/現在のパスワードの変更/その他の機密性の高い操作を行うことを許容する。
- トークンの信頼性を確認しない。
- 署名なし/署名の弱いJWTトークン({"alg":"none"})を受け入れる
- JWTの有効期限を検証しない。
- プレーンテキスト、暗号化されていない、または弱くハッシュ化されたパスワードを使用する。
- 弱い暗号化キーを使用する。
さらに、次の場合、マイクロサービスは脆弱になる。
- 他のマイクロサービスが認証なしでアクセスできる
- 弱いトークンまたは予測可能なトークンを使用して認証を強制する

脅威エージェント/攻撃ベクトル

API 固有/悪用が簡単
詳細
- 認証メカニズムは誰にでも公開されるため、攻撃者の格好の標的となる。
- 一部の認証問題を悪用するには、より高度な技術スキルが必要になる場合がありますが、悪用ツールは一般的に入手可能。

影響

技術的に重大: ビジネス固有
詳細
- 攻撃者は、システム内の他のユーザーのアカウントを完全に制御し、ユーザーの個人データを読み取り、ユーザーに代わって機密のアクションを実行する可能性がある。
- システムが攻撃者の行動と正当なユーザーの行動を区別できる可能性はほとんどない。

予防方法

API(モバイル/Web/ワンクリック認証を実装するディープリンクなど)に対する認証に使用できるすべてのフローを理解する。
認証メカニズムについて理解する。
- それらが何にどのように使用されるかを必ず理解する。
- OAuthは認証ではなく、APIキーでもありません。
認証、トークンの生成、またはパスワードの保存において車輪の再発明を行わない。
- 標準を使用してください。
認証情報の回復/パスワードを忘れた場合のエンドポイントは、ブルートフォース、レート制限、ロックアウト保護の観点からログインエンドポイントとして扱う。
機密性の高い操作(アカウント所有者の電子メールアドレス/2FA電話番号の変更など)には再認証を必要とする。
OWASP認証チートシートを使用してチェックを実施する。
可能な場合は、多要素認証を実装する。
認証エンドポイントに対する資格情報スタッフィング、辞書攻撃、およびブルートフォース攻撃を軽減するブルートフォース対策メカニズムを実装する。
- このメカニズムは、APIの通常のレート制限メカニズムよりも厳格である必要があります。
アカウントロックアウト/キャプチャメカニズムを実装して、特定のユーザーに対するブルートフォース攻撃を防ぐ。
- 弱いパスワードのチェックを実装します。
APIキーはユーザー認証に使用しない。
- APIキーはAPIクライアントの認証にのみ使用する。

API3:2023 - Broken Object Property Level Authorization

オブジェクトのプロパティ対し適切な認証がされていない

説明

API エンドポイントを使用してユーザーにオブジェクトへのアクセスを許可する場合、ユーザーがアクセスしようとしている特定のオブジェクトのプロパティにアクセスできることを検証することが重要。
次の場合は脆弱です
- 機密であると考えられ、ユーザーが読み取ってはならないオブジェクトのプロパティが取得できる。
- ユーザーはアクセスできない機密オブジェクトのプロパティの値を変更、追加/削除することができる。

脅威エージェント/攻撃ベクトル

API 固有: 悪用が簡単
詳細
- APIは、すべてのオブジェクトのプロパティを返すエンドポイントを公開する傾向がある。
  - これは特にREST APIに当てはまります。GraphQLなどの他のプロトコルの場合、返されるプロパティを指定するために細工されたリクエストが必要になる場合がある。
  - 操作できるこれらの追加プロパティを特定するには、より多くの労力が必要ですが、このタスクを支援するために利用できる自動化ツールがいくつかあります。

影響

技術的中程度 : ビジネス固有
詳細
- プライベート/機密オブジェクトのプロパティに不正にアクセスすると、データの漏洩、データの損失、またはデータの破損が発生する可能性がある。
- 特定の状況下では、オブジェクトのプロパティへの不正アクセスにより、権限昇格やアカウントの部分的/完全な乗っ取りが発生する可能性がある。

予防方法

APIエンドポイントを使用してオブジェクトを公開する場合は、公開するオブジェクトのプロパティにユーザーがアクセスできることを常に確認する。
to_json()やto_string()などの汎用メソッドの使用は避けてください。代わりに、特に返したい特定のオブジェクトプロパティを厳選する。
可能であれば、クライアントの入力をコード変数、内部オブジェクト、またはオブジェクトプロパティに自動的にバインドする関数(「一括割り当て」)の使用は避ける。
クライアントによって更新される必要があるオブジェクトのプロパティへの変更のみを許可する。
追加のセキュリティ層としてスキーマベースの応答検証メカニズムを実装する。
- このメカニズムの一部として、すべてのAPIメソッドによって返されるデータを定義して適用する。
エンドポイントのビジネス/機能要件に従って、返されるデータ構造を最小限に抑える。

API4:2023 - Unrestricted Resource Consumption

無制限のリソース消費

説明

APIリクエストを満たすには、ネットワーク帯域幅、CPU、メモリ、ストレージなどのリソースが必要。場合によっては、必要なリソースがAPI統合を通じてサービスプロバイダーによって利用可能になり、電子メール/SMS/電話の送信、生体認証検証などのリクエストごとに料金が支払われる。
次の制限のうち少なくとも1つが欠落しているか、不適切に設定されている場合(例:低すぎる/高すぎる)、APIは脆弱になる。
- 実行タイムアウト
- 最大割り当て可能メモリ
- ファイル記述子の最大数
- 最大プロセス数
- アップロードファイルの最大サイズ
- 単一の API クライアントリクエストで実行するオペレーションの数 (例: GraphQL バッチ処理)
- 1 回のリクエストとレスポンスで返されるページあたりのレコード数
- サードパーティサービスプロバイダーの支出制限

脅威エージェント/攻撃ベクトル

API 固有: 悪用可能性の中間
詳細
- 悪用には単純なAPIリクエストが必要。
- 複数の同時リクエストは、単一のローカルコンピューターから、またはクラウドコンピューティングリソースを使用して実行できる。
- 利用可能な自動化ツールのほとんどは、高負荷のトラフィックによってDoSを引き起こし、APIのサービスレートに影響を与えるように設計される。

影響

技術的に重大: ビジネス固有
詳細
- DoSによるリソース枯渇によるつながる可能性がある。
- CPU需要の増加やクラウドストレージのニーズの増加などにより、インフラストラクチャ関連などの運用コストの増加につながる可能性もある。

予防方法

メモリ、CPU、再起動回数、ファイル記述子、コンテナ/サーバーレスコード(Lambdaなど)などのプロセスを簡単に制限できるソリューションを使用する。
文字列の最大長、配列内の要素の最大数、アップロードファイルの最大サイズ(ローカルに保存されているかクラウドストレージに保存されているかに関係なく)など、すべての受信パラメーターとペイロードのデータの最大サイズを定義して強制する。
定義された時間枠内でクライアントがAPIと対話できる頻度に制限を実装する(レート制限)。
レート制限は、ビジネスニーズに基づいて微調整する必要がある。
- 一部のAPIエンドポイントでは、より厳格なポリシーが必要になる場合がある。
単一のAPIクライアント/ユーザーが単一の操作を実行できる回数または頻度を制限/調整する。
- 例:OTPの検証、またはワンタイムURLにアクセスせずにパスワードの回復をリクエスト。
クエリ文字列とリクエスト本文パラメータ、特に応答で返されるレコード数を制御するパラメータに対して適切なサーバー側検証を追加する。
すべてのサービスプロバイダー/API統合の支出制限を構成する。
- 支出制限を設定できない場合は、代わりに請求アラートを構成する必要がある。

API5:2023 - Broken Function Level Authorization

関数レベルの認証の欠陥

説明

壊れた機能レベルの認可の問題を見つける最善の方法は、ユーザー階層、アプリケーション内のさまざまな役割またはグループを念頭に置きながら、認可メカニズムを詳細に分析し、次の質問をすること。
- 一般ユーザーは管理エンドポイントにアクセスできるか?
- ユーザーは、単にHTTPメソッドを変更する(例:GETからDELETE)だけで、アクセスすべきではない機密性の高いアクション(例:作成、変更、または削除)を実行できるか?
- グループXのユーザーは、エンドポイントURLとパラメーター(/api/v1/users/export_allなど)を推測するだけで、グループYのユーザーにのみ公開される関数にアクセスできるか?

APIエンドポイントがURLパスのみに基づいて通常のものである、または管理用であると想定しない。

開発者は、/api/adminsなどの特定の相対パスでほとんどの管理エンドポイントを公開することを選択する場合があるが、これらの管理エンドポイントが/api/usersなどの通常のエンドポイントとともに他の相対パスで見つかることは非常に一般的。

脅威エージェント/攻撃ベクトル

API 固有/悪用が簡単
詳細
- 悪用するには、攻撃者が匿名ユーザーまたは通常の非特権ユーザーとしてアクセスすべきではないAPIエンドポイントに正規のAPI呼び出しを送信する必要がある。
- 公開されたエンドポイントは簡単に悪用されてしまう。

影響

技術的に重大: ビジネス固有
詳細
- このような欠陥により、攻撃者は不正な機能にアクセスすることができる。
- 管理機能はこの種の攻撃の主なターゲットであり、データ漏洩、データ損失、またはデータ破損につながる可能性がある。
- 最終的にはサービスの中断につながる可能性がある。

予防方法

アプリケーションには、すべてのビジネス機能から呼び出される、一貫性があり分析しやすい承認モジュールが必要。多くの場合、このような保護は、アプリケーションコードの外部にある1つ以上のコンポーネントによって提供される。
強制メカニズムはデフォルトですべてのアクセスを拒否し、すべての機能にアクセスするには特定のロールへの明示的な許可を必要とする。
アプリケーションとグループ階層のビジネスロジックを念頭に置きながら、機能レベルの承認の欠陥に対してAPIエンドポイントを確認する。
すべての管理コントローラが、ユーザーのグループ/ロールに基づいて認可チェックを実装する管理抽象コントローラから継承していることを確認する。
通常のコントローラ内の管理機能が、ユーザーのグループとロールに基づいて承認チェックを実装していることを確認する。

API6:2023 - Unrestricted Access to Sensitive Business Flows

機密性の高いビジネスフローへの無制限のアクセス

説明

APIエンドポイントを作成するときは、それがどのビジネスフローを公開するかを理解することが重要。ビジネスフローの中には、過度のアクセスがビジネスに損害を与える可能性があるという意味で、他のビジネスフローよりも機密性が高いものがある。

機密性の高いビジネスフローとそれに関連する過剰なアクセスのリスクの一般的な例:

製品フローの購入
- 攻撃者は需要の高い商品の在庫をすべて一度に購入し、より高い価格で転売することができる(スキャルピング)
コメント/投稿フローの作成
- 攻撃者がシステムにスパムを送信する可能性がある
予約
- 攻撃者は利用可能なすべてのタイムスロットを予約し、他のユーザーがシステムを使用できないようにすることができる。過剰アクセスのリスクは業界や企業によって異なる可能性がある。
- たとえば、スクリプトによる投稿の作成は、あるソーシャルネットワークではスパムのリスクとみなされますが、別のソーシャルネットワークでは推奨される場合がある。

APIエンドポイントへのアクセスを適切に制限せずに機密性の高いビジネスフローを公開すると、APIエンドポイントは脆弱になる。

脅威エージェント/攻撃ベクトル

API 固有/悪用が簡単
詳細
- 悪用には通常、APIに裏付けられたビジネスモデルの理解、機密性の高いビジネスフローの発見、これらのフローへのアクセスの自動化が含まれ、ビジネスに損害を与える。

影響

技術的中程度 : ビジネス固有
詳細
- 一般に、技術的な影響は期待されない。
- 悪用はさまざまな方法でビジネスに損害を与える可能性がある。
- たとえば、正規ユーザーが製品を購入できなくなったり、ゲームの内部経済のインフレを引き起こしたりする可能性がある。

予防方法

緩和計画は2つの層で行う必要があります。

ビジネス
- 過度に使用するとビジネスに悪影響を及ぼす可能性のあるビジネスフローを特定する。
エンジニアリング
- ビジネスリスクを軽減するために適切な保護メカニズムを選択する。

保護メカニズムには、より単純なものもあれば、実装がより難しいものもあります。自動化された脅威の速度を低下させるために、次の方法が使用される。

デバイスのフィンガープリンティング:
- 予期しないクライアントデバイス(ヘッドレスブラウザなど)へのサービスを拒否すると、攻撃者はより高度なソリューションを使用する傾向があり、そのためコストが高くなる。
人間の検出:
- キャプチャまたはより高度な生体認証ソリューション(例:タイピングパターン)を使用
人間以外のパターン:
- ユーザーフローを分析して人間以外のパターンを検出する(例:ユーザーが1秒以内に「カートに追加」および「購入を完了」機能にアクセスした) Tor出口ノードと既知のプロキシのIPアドレスをブロックすることを検討するべき。

マシンによって直接使用されるAPI(開発者APIやB2BAPIなど)へのアクセスを保護し、制限します。これらは必要な保護メカニズムをすべて実装していないことが多いため、攻撃者にとって簡単な標的になる傾向がある。

API7:2023 - Server Side Request Forgery

Server Side Request Forgery(サーバー側のリクエスト偽造)
日本語に訳すと不自然ですね、、、

説明

サーバーサイドリクエストフォージェリ(SSRF)の欠陥は、APIがユーザー指定のURLを検証せずにリモートリソースを取得するときに発生する。
これにより、攻撃者は、ファイアウォールやVPNで保護されている場合でも、アプリケーションに細工したリクエストを予期しない宛先に送信させることができる。
アプリケーション開発における最新の概念により、SSRFはより一般的になり、より危険なものになっている。
さらに一般的なのは、Webhook、URLからのファイル取得、カスタムSSO、URLプレビューなどの概念により、開発者はユーザー入力に基づいて外部リソースにアクセスすることを奨励する。
さらに危険
- クラウドプロバイダー、Kubernetes、Dockerなどの最新のテクノロジーは、予測可能な既知のパスでHTTP経由で管理チャネルと制御チャネルを公開する。
- これらのチャネルはSSRF攻撃のターゲットになりやすい。
また、最新のアプリケーションの接続された性質により、アプリケーションからのアウトバウンドトラフィックを制限することはさらに困難になる。
SSRFリスクは常に完全に排除できるわけではない。
- 保護メカニズムを選択する際には、ビジネスのリスクとニーズを考慮することが重要。

脅威エージェント/攻撃ベクトル

API 固有/悪用が簡単
詳細
- 悪用するには、攻撃者はクライアントから提供されたURIにアクセスするAPIエンドポイントを見つける必要がある。
- 一般に、基本SSRF(応答が攻撃者に返されるとき)は、攻撃が成功したかどうかについて攻撃者がフィードバックを持たないブラインドSSRFよりも悪用しやすくなる。

影響

技術的中程度 : ビジネス固有
詳細
- 悪用に成功すると、内部サービスの列挙(ポートスキャンなど)、情報漏洩、ファイアウォールのバイパス、またはその他のセキュリティメカニズムが発生する可能性がある。
- 場合によっては、DoSが発生したり、サーバーが悪意のあるアクティビティを隠すためのプロキシとして使用されたりする可能性がある。

予防方法

ネットワーク内のリソース取得メカニズムを分離する。
- 通常、これらの機能は、内部リソースではなくリモートリソースを取得することを目的としている。
可能な限り、次の許可リストを使用する。
- リモートオリジンユーザーはリソースをダウンロードすることが期待されます(例:GoogleDrive、Gravatarなど)。
- URLスキームとポート
- 特定の機能で受け入れられるメディアタイプ
HTTPリダイレクトを無効にする。
URL解析の不一致によって引き起こされる問題を回避するには、十分にテストされ、保守されているURLパーサーを使用する。
クライアントが提供したすべての入力データを検証し、サニタイズする。
生の応答をクライアントに送信しない。

API8:2023 - Security Misconfiguration

セキュリティの構成ミス

説明

次の場合、APIは脆弱になる可能性がある。
- APIスタックのどの部分でも適切なセキュリティ強化が欠落している場合、またはクラウドサービスに不適切に設定された権限がある場合
- 最新のセキュリティパッチが適用されていない、またはシステムが古い
- 不要な機能が有効になっている(HTTP動詞、ロギング機能など)
- HTTPサーバーチェーン内のサーバーによる受信リクエストの処理方法に矛盾がある
- トランスポート層セキュリティ(TLS)がない
- セキュリティまたはキャッシュ制御ディレクティブはクライアントに送信されない
- Cross-OriginResourceSharing(CORS)ポリシーが欠落しているか、不適切に設定されている
- エラーメッセージにはスタックトレースが含まれたり、他の機密情報が公開されたりする

脅威エージェント/攻撃ベクトル

API 固有/悪用が簡単
詳細
- 攻撃者は多くの場合、パッチが適用されていない欠陥、共通のエンドポイント、安全でないデフォルト構成で実行されているサービス、または保護されていないファイルやディレクトリを見つけて、システムへの不正アクセスや知識を取得しようとする。
- このほとんどは公知であり、悪用される可能性がある。

影響

技術的に重大: ビジネス固有
詳細
- セキュリティの構成ミスは、機密のユーザーデータを公開するだけでなく、サーバー全体の侵害につながる可能性のあるシステムの詳細も公開する。

予防方法

APIライフサイクルには以下を含める必要がある。
- 反復可能な強化プロセスにより、適切にロックダウンされた環境を迅速かつ簡単に展開できる。
- APIスタック全体の構成を確認して更新するタスク。
  - レビューには、オーケストレーションファイル、API コンポーネント、クラウドサービス(S3バケットの権限など)を含める必要がある。
- すべての環境における構成と設定の有効性を継続的に評価するための自動プロセス
APIライフサイクルには以下を含める必要がある。
- 反復可能な強化プロセスにより、適切にロックダウンされた環境を迅速かつ簡単に展開できる。
- APIスタック全体の構成を確認して更新するタスク。
  - レビューには、オーケストレーションファイル、API コンポーネント、クラウドサービス(S3バケットの権限など)を含める必要がある。
- すべての環境における構成と設定の有効性を継続的に評価するための自動プロセス
さらに：
- クライアントからAPIサーバーおよびダウンストリーム/アップストリームコンポーネントへのすべてのAPI通信は、内部APIか公開APIかに関係なく、暗号化された通信チャネル(TLS)経由で行われるようにする。
- 各APIがどのHTTP動詞にアクセスできるかを具体的に指定する。
  - 他のすべてのHTTP動詞(例:HEAD)は無効にする必要がある。
- ブラウザベースのクライアント(WebAppフロントエンドなど)からのアクセスを想定しているAPIは、少なくとも次のことを行う必要がある。
  - 適切なCross-OriginResourceSharing(CORS)ポリシーを実装する
  - 該当するセキュリティヘッダーを含める
受信するコンテンツタイプ/データ形式を、ビジネス/機能要件を満たすものに制限する。
非同期の問題を回避するために、HTTPサーバーチェーン内のすべてのサーバー(ロードバランサー、リバースプロキシおよびフォワードプロキシ、バックエンドサーバーなど)が受信リクエストを均一な方法で処理するようにする。
該当する場合は、エラー応答を含むすべてのAPI応答ペイロードスキーマを定義して適用し、例外トレースやその他の貴重な情報が攻撃者に送り返されるのを防ぐ。

API9:2023 - Improper Inventory Management

不適切な在庫管理

説明

APIと最新のアプリケーションの無秩序で接続された性質は、新たな課題をもたらす。組織にとって、独自のAPIとAPIエンドポイントを十分に理解し、可視化することだけでなく、APIがどのようにデータを保存したり、外部のサードパーティとデータを共有したりしているかについても理解することが重要。

複数のバージョンのAPIを実行するには、APIプロバイダーからの追加の管理リソースが必要となり、攻撃対象領域が拡大する。
次の場合、APIには「ドキュメントの盲点」がある。

APIホストの目的は明確ではなく、次の質問に対する明確な答えがない。
- APIはどの環境で実行されていますか(本番、ステージング、テスト、開発など)?
- APIへのネットワークアクセスを持つ必要があるのは誰か(パブリック、内部、パートナーなど)?
- どのAPIバージョンが実行されているか?
- ドキュメントが存在しないか、既存のドキュメントが更新されていない。
- 各APIバージョンには廃止計画がない。
- ホストのインベントリが見つからないか、古い。
- サードパーティ側で侵害が発生した場合に備えて、機密データフローの可視性とインベントリは、インシデント対応計画の一部として重要な役割を果たす。

次の場合、APIには「データフローの盲点」がある。

APIが機密データをサードパーティと共有する「機密データフロー」がる
ビジネス上の正当性やフローの承認がない
在庫やフローの可視性がない
どの種類の機密データが共有されているかを詳細に把握できない

脅威エージェント/攻撃ベクトル

API 固有/悪用が簡単
詳細
- 脅威エージェントは通常、古いAPIバージョンや、パッチを適用せずに実行され、弱いセキュリティ要件を使用しているエンドポイントを介して不正アクセスを受ける。
- 場合によってはエクスプロイトが利用可能。
- あるいは、データを共有する理由がないサードパーティを通じて機密データにアクセスする可能性がある。

影響

技術的中程度 : ビジネス固有
詳細
- 攻撃者は機密データにアクセスしたり、サーバーを乗っ取ったりする可能性があります。
- 場合によっては、異なるAPIバージョン/デプロイメントが実際のデータを含む同じデータベースに接続されることがあります。
- 脅威エージェントは、古いAPIバージョンで利用可能な非推奨のエンドポイントを悪用して、管理機能にアクセスしたり、既知の脆弱性を悪用したりする可能性があります。

予防方法

すべてのAPIホストの一覧を作成し、API環境(本番、ステージング、テスト、開発など)、ホストへのネットワークアクセスを持つ必要があるユーザー(パブリック、内部、パートナーなど)、およびAPIバージョンに焦点を当てて、それぞれの重要な側面を文書化する。
統合サービスの一覧を作成し、システム内でのサービスの役割、交換されるデータ(データフロー)、およびその機密性などの重要な側面を文書化する。
認証、エラー、リダイレクト、レート制限、クロスオリジンリソース共有(CORS)ポリシー、エンドポイント(パラメータ、リクエスト、レスポンスなど)などのAPIのあらゆる側面を文書化する。
オープンスタンダードを採用してドキュメントを自動的に生成する。
CI/CDパイプラインにドキュメントビルドを含める。
APIドキュメントは、APIの使用を許可されたユーザーのみが利用できるようにする。
現在の運用バージョンだけでなく、公開されているAPIのすべてのバージョンに対して、APIセキュリティ固有のソリューションなどの外部保護手段を使用する。
非実稼働APIデプロイメントで実稼働データを使用することは避ける。
- これが避けられない場合は、これらのエンドポイントは運用環境のエンドポイントと同じセキュリティ処理を受ける必要がありる。
APIの新しいバージョンにセキュリティの強化が含まれている場合は、リスク分析を実行して、古いバージョンに必要な緩和アクションを通知する。
- たとえば、APIの互換性を損なうことなく改善をバックポートできるかどうか、または古いバージョンをすぐに削除してすべてのクライアントを最新バージョンに強制的に移行する必要があるかどうかなど。