Skip to content

API9:2023 不適切なインベントリ管理（Improper Inventory Management）

Threat agents / Attack vectors（脅威エージェント／攻撃ベクター） Security Weakness（セキュリティの弱点） Impacts（影響）
API 固有：悪用難易度（Exploitability） 容易

脅威エージェントは、旧バージョン API や 未パッチで弱い要件 のエンドポイントを使って不正アクセスを得るのが一般的。既知のエクスプロイトが存在する場合もある。あるいは、本来共有不要な 第三者連携 を経由して機微データにアクセスする。		 蔓延度（Prevalence） 広範 ： 検出可能性（Detectability） 平均

古いドキュメント は脆弱性の発見・修正を難しくする。資産台帳や廃止戦略の欠如 は未パッチシステムの稼働につながり、機微データ漏えいを招く。マイクロサービス等の現代的概念（クラウド、K8S）により 不要に公開された API ホスト が見つかりがち。Google Dork、DNS 列挙、各種検索エンジン（webcam、router 等）で容易に標的を発見できる。		 技術的影響（Technical） 中程度 ： ビジネス影響（Business） ケース依存

攻撃者は 機微データ取得 や サーバ乗っ取り を達成し得る。異なる API バージョン／デプロイが 実データの同一 DB を共有していることがあり、廃止済みエンドポイント を悪用して管理機能へ到達、既知脆弱性の再悪用に繋がる。

API は脆弱か？

API とモダンアプリの 分散・連結 という性質は新たな課題をもたらす。自組織の API／エンドポイントの可視性 だけでなく、API が どのように外部第三者とデータを保存・共有しているか も把握することが重要。

複数バージョン の API を同時運用すると、管理負荷 と 攻撃面 が拡大する。

次のような場合、API には 「ドキュメントの死角」 がある：

  • API ホストの 目的が不明確 で、以下に明確に答えられない

  • 稼働環境は？（本番／ステージング／テスト／開発）

  • ネットワークアクセス権者は？（パブリック／社内／パートナー）

  • 稼働中の API バージョン は？

  • ドキュメントが 未整備、または 更新されていない。

  • 各 API バージョンの廃止計画 がない。
  • ホストのインベントリ が欠落／陳腐化している。

第三者側で侵害が発生した場合に備え、機微データフローの可視性・台帳 はインシデント対応計画の重要要素。

次のような場合、API には 「データフローの死角」 がある：

  • API が第三者と 機微データ を共有するフローにおいて

  • 業務上の正当化や承認 がない

  • フローの 台帳や可視性 がない
  • 共有している 機微データの種類の詳細可視性 がない

攻撃シナリオ例

シナリオ #1

ある SNS は、パスワードリセットトークンの総当たりを防ぐ レート制限 を導入したが、これは API コードではなく、クライアントと公式 API（api.socialnetwork.owasp.org）の 間の別コンポーネント に実装されていた。研究者は ベータホスト（beta.api.socialnetwork.owasp.org）を発見。そこでは同じ API が稼働していたが、レート制限が未適用。研究者は 6 桁トークンを単純総当たりで 任意ユーザーのパスワードをリセット できた。

シナリオ #2

SNS は外部の独立アプリ開発者との 連携 を許可。プロセスの一環でエンドユーザーに 同意 を求め、SNS がユーザーの 個人情報を外部アプリと共有 できるようにしている。

しかし SNS と外部アプリ間の データフローが緩く無監視 なため、外部アプリはユーザー本人の情報に加え、友人全員のプライベート情報 にもアクセス可能。コンサル企業が 悪意あるアプリ を作成し 27 万人 の同意を獲得。欠陥により 5,000 万人 のプライベート情報へアクセスし、その後 悪用目的で販売 した。

防止方法（How To Prevent）

  • すべての API ホストを棚卸し、各ホストの重要事項を文書化（環境：本番／Stg／Test／Dev、ネットワーク公開範囲：公開／社内／パートナー、API バージョン 等）。
  • 連携サービスを棚卸し、役割・交換データ（データフロー）・機微度など重要事項を文書化。
  • 認証、エラー、リダイレクト、レート制限、CORS ポリシー、エンドポイント（パラメータ／リクエスト／レスポンス）など API の全側面を文書化。
  • オープン標準 を採用して 自動生成ドキュメント を構築し、CI/CD に組み込む。
  • API ドキュメントは 利用許可のある者のみに提供。
  • 公開中の あらゆる API バージョン に対し、API セキュリティ専用ソリューション など外部防御を適用（現行本番だけに限定しない）。
  • 本番データを非本番 API で使用しない。不可避なら 本番同等のセキュリティ を適用。
  • 新バージョンに セキュリティ改善 が含まれる場合、旧版に対する リスク分析 を行い、互換性を壊さずバックポート 可能か、旧版の迅速廃止・強制移行 が必要かを判断。

References

External