API9:2023 不適切なインベントリ管理 (Improper Inventory Management)
| 脅威エージェント/攻撃手法 | セキュリティ上の弱点 | 影響 |
|---|---|---|
API 依存 : 悪用難易度 容易 | 普及度 広範 : 検出難易度 平均的 | 技術的影響 中程度 : ビジネス依存 |
脅威エージェントは一般的に古い API バージョンやパッチを適用せずに実行して脆弱なセキュリティ要件を使用したままのエンドポイントを通じて、不認可アクセスを行います。場合によってはエクスプロイトが利用可能です。あるいは、データを共有する理由のないサードパーティを通じて機密データにアクセスすることもあります。 | ドキュメントが古いと脆弱性の発見や修正がより難しくなります。資産インベントリやリタイアメント戦略がないと、パッチを適用していないシステムが稼働し、機密データの漏洩につながります。アプリケーションのデプロイを容易にし独立したものにする、マイクロサービスなどの最近のコンセプト (クラウドコンピューティング、K8S など) により、不必要に露出した API ホストを見つかることがよくあります。単純な Google Dorking、DNS 列挙、あるいはインターネットに接続されているさまざまな種類のサーバー (ウェブカメラ、ルーター、サーバーなど) に特化した検索エンジンを使用すれば、ターゲットを発見するのに十分です。 | 攻撃者は機密データにアクセスしたり、サーバーを乗っ取ることすらできます。異なる API バージョンやデプロイメントが実データのある同じデータベースに接続されることがあります。脅威エージェントは古い API バージョンで利用可能な非推奨のエンドポイントを悪用して、管理機能にアクセスしたり既知の脆弱性を悪用する可能性があります。 |
その API は脆弱か？
API と最近のアプリケーションのスプロールとコネクテッドの性質は新たな課題をもたらします。 組織にとって重要なのは、自社の API と API エンドポイントを十分に理解して可視化するだけでなく、API がどのようにデータを保存したり、外部のサードパーティとデータを共有するかについても理解することです。
複数のバージョンの API を実行すると、API プロバイダから管理リソースを追加する必要があり、攻撃対象領域が拡大します。
API には以下のような「ドキュメントの盲点」があるかもしれません。
API ホストの目的が不明確であり、以下の質問に対する明確な答えがありません。
API はどの環境 (本番環境、ステージング環境、テスト環境、開発環境) で実行していますか？
API へネットワークアクセスできるのは誰 (パブリック、内部、パートナーなど) ですか？
どの API バージョンが動作していますか？
ドキュメントがないか、既存のドキュメントが更新されていません。
各 API バージョンのリタイアメントプランがありません。
ホストのインベントリがないか、古くなっています。
サードパーティ側で侵害が発生した場合に備えて、機密データフローの可視性とインベントリはインシデント対応計画の一部として重要な役割を果たします。
API は以下のような「データフローの盲点」があるかもしれません。
API が機密データをサードパーティと共有する「機密データフロー」がありますが、以下のような状況です。
そのフローについてビジネス上の正当性や承認がありません。
そのフローのインベントリや可視性がありません。
どのような機密データが共有されているかを詳細に把握できません。
攻撃シナリオの例
シナリオ #1
あるソーシャルネットワークでは攻撃者がブルートフォースを使用してリセットパスワードトークンを推測することをブロックするレート制限メカニズムを実装しました。 このメカニズムは API コード自体の一部としてではなく、クライアントと公式 API (api.socialnetwork.owasp.org) との間にある別のコンポーネントに実装されました。 ある研究者はリセットパスワードメカニズムを含む同じ API を実行するベータ API ホスト (beta.api.socialnetwork.owasp.org) を見つけましたが、レート制限メカニズムはありませんでした。 この研究者は単純なブルートフォースを使用して 6 桁のトークンを推測することで、任意のユーザーのパスワードをリセットできました。
シナリオ #2
あるソーシャルネットワークでは独立系アプリの開発者がそのソーシャルネットワークと統合できます。 このプロセスの一環として、エンドユーザーからの同意が要求され、このソーシャルネットワークはユーザーの個人情報を独立系アプリと共有できます。
ソーシャルネットワークと独立系アプリの間のデータフローは制限や監視が十分ではないため、独立系アプリはユーザー情報だけでなく、その友人すべての個人情報にもアクセスできます。
あるコンサルティング会社が悪意のあるアプリを作成し、270,000 ユーザーの同意を得ることができました。 この欠陥により、コンサルティング会社は 50,000,000 ユーザーの個人情報にアクセスできました。 その後、コンサルティング会社はこの情報を悪意のある目的で販売します。
防止方法
すべての API ホスト のインベントリを作成し、API 環境 (本番環境、ステージング環境、テスト環境、開発環境など) 、ホストへネットワークアクセスできる人 (パブリック、内部、パートナーなど) 、API バージョンに焦点を当てて、それら各々について重要な側面を文書化します。
統合されたサービス のインベントリを作成し、システムの役割、交換されるデータ (データフロー) 、それらの機密性などの重要な側面を文書化します。
認証、エラー、リダイレクト、レート制限、クロスオリジンリソース共有 (CORS) ポリシー、エンドポイントなどの API のすべての側面を、パラメータ、リクエスト、レスポンスを含めて文書化します。
オープンスタンダードを採用してドキュメントを自動的に生成します。CI/CD パイプラインにドキュメントビルドを含めます。
API ドキュメントは API の使用を認可された者のみが利用できるようにします。
現在の本番バージョンだけでなく、API のすべての公開バージョンに対して、API セキュリティに特化したソリューションなどの外部保護手段を使用します。
本番以外の API デプロイメントで本番データを使用することは避けます。やむを得ない場合には、これらのエンドポイントには本番環境と同じセキュリティ処置を施す必要があります。
新しいバージョンの API にセキュリティの改善が含まれている場合には、リスク分析を実施し、古いバージョンに必要な緩和策を通知します。たとえば、API の互換性を損なうことなくその改善をバックポートできるかどうか、古いバージョンを速やかに削除してすべてのクライアントを強制的に最新バージョンに移行する必要があるかどうかなどです。
参考資料
その他
Last updated