| 脅威エージェント / 攻撃ベクトル | セキュリティ弱点 | 影響 |
|---|---|---|
| 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
あるソーシャルネットワークは、独立したアプリの開発者がそれと統合することを可能にしています。このプロセスの一部として、エンドユーザーから同意が求められ、ソーシャルネットワークがエンドユーザーの個人情報を独立したアプリと共有することができます。
ソーシャルネットワークと独立したアプリ間のデータフローは、制限が不十分で監視されていないため、独立したアプリはユーザー情報だけでなく、すべての友達のプライベート情報にアクセスできるようになっています。
あるコンサルティング会社が悪意のあるアプリを作成し、27万人のユーザーから同意を得ることに成功しました。この欠陥のため、コンサルティング会社は5,000万人のユーザーのプライベート情報にアクセスできました。後に、コンサルティング会社はこの情報を悪用する目的で販売しました。
防止方法
- すべてのAPIホストをインベントリに登録し、それぞれについて重要な側面を文書化します。APIの環境（例：本番、ステージング、テスト、開発）、ホストにネットワークアクセスすべきユーザー（例：公開、内部、パートナー）、およびAPIバージョンに焦点を当てます。
- 統合されたサービスのインベントリを作成し、システム内での役割、交換されるデータ（データフロー）、およびその機密性などの重要な側面を文書化します。
- 認証、エラー、リダイレクト、レート制限、クロスオリジンリソース共有（CORS）ポリシーなど、APIのすべての側面を文書化します。これには、パラメータ、リクエスト、およびレスポンスが含まれます。
- オープン標準を採用して文書化を自動化します。文書作成をCI/CDパイプラインに組み込みます。
- APIの文書をAPIを使用する権限のある者にのみ公開します。
- 現在の本番バージョンだけでなく、すべての公開されたAPIバージョンに対してAPIセキュリティ専用ソリューションなどの外部保護措置を使用します。
- 非本番のAPI展開で本番データを使用することを避けます。これが避けられない場合、これらのエンドポイントは本番と同じセキュリティ対策を受けるべきです。
- 新しいAPIバージョンにセキュリティの改善が含まれている場合、リスク分析を実施して、古いバージョンに必要な対策を通知します。たとえば、API互換性を壊さずに改善をバックポートすることが可能かどうか、または古いバージョンをすぐに削除してすべてのクライアントを最新バージョンに移行させる必要があるかどうかを判断します。