海外ブログ

OWASP Top 10 API セキュリティリスク：2023年版

2023.03.28

2023年3月17日、Paul Dughi

OWASP API セキュリティプロジェクトは、2023年の API セキュリティリスクトップ 10 を更新しています。2019年以来の更新で、新しいリストではこれまでと同じリスクもあれば、新しく追加されたものも、削除されたものもあります。たとえば、ロギングとモニタリング、インジェクションは、依然として重要な要因ではあるものの、トップ 10 には入っていません。新たに加わったもののなかには、SSRF（サーバーサイドリクエストフォージェリー）や API の安全でない利用があります。

現時点で、リストはまだ確定していませんが、OWASP のGithubサイトで公開されており、レビューやコメントが可能です。今のところ、2023 年版リストの項目は以下の通りです。

オブジェクトレベルの認可の不備
認証の不備
オブジェクトプロパティレベルの認可不備
無制限な資源消費
機能レベルの認可の不備
サーバーサイドリクエストフォージェリ
セキュリティの設定不備
自動化された脅威からの保護の不足
不適切な資産管理
安全でないAPIの消費

1. オブジェクトレベルの認可の不備

オブジェクトレベルの認可は、一般的にユーザー検証のためにコードレベルで実装され、オブジェクトへのアクセスを制限する制御方法です。オブジェクトレベルの認可が適切に実施されない場合、システムを危険な状態にさらす可能性があります。Uberでは、攻撃者がユーザーの電話番号を含む API リクエストを送信してトークンにアクセスし、システムを操作したことでこのような脆弱性が発覚しました。

攻撃ベクター：リクエスト内で送信されるオブジェクト ID を操作することで、API エンドポイントを悪用する攻撃です。この問題は、API ベースのアプリケーションにおいて残念ながらとてもよく見られます。サーバー側のコンポーネントがクライアントの状態を完全に追跡せず、オブジェクト ID に多くを依存しているからです。

セキュリティの弱点：認可とアクセス制御は複雑なものです。適切なプロトコルと設定があっても、開発者は機密性の高いオブジェクトにアクセスする前に認可チェックを行うことを忘れてしまうことがあります。このような状態は、自動テストではなかなか事前に検出されません。

2. 認証の不備

認証エンドポイントは、ブルートフォース攻撃、クレデンシャルスタッフィング、弱い暗号化キー、認証を必要としないほかのマイクロサービスへの接続など、多くのリスクに対して脆弱です。

攻撃ベクター：これらのエンドポイントは、組織外の人がアクセスできる可能性があるため、いくつかの潜在的な脅威が存在します。しばしば、認証のための境界全体を完全に保護できていなかったり、適切なセキュリティ・プロトコルを実装していなかったりします。

セキュリティの弱点：OWASPは、エンドポイント認証に関する２つの具体的な問題点を指摘しています。

追加の保護レベルを含む保護メカニズムの欠如
認証メカニズムの不適切な実装、またはアプリケーションに対する誤ったメカニズムの使用

3. オブジェクトプロパティレベルの認可の不備

API 経由でオブジェクトにアクセスする場合、ユーザーが特定のオブジェクトプロパティにアクセスする権限を持っていることのバリデーションが必要です。オブジェクトプロパティレベルで認可に不備があると、権限のないユーザーがオブジェクトにアクセスしたり、変更したりすることができるようになります。

攻撃ベクター：脅威者は脆弱な API エンドポイントを悪用し、攻撃者が利用できないはずのオブジェクトのプロパティ値を読み取り、変更、追加、削除します。

セキュリティ上の弱点：開発者が機能やオブジェクトへのユーザーアクセスのバリデーションを提供しても、ユーザーがオブジェクト内の特定のプロパティへのアクセスを許可されているかどうかをバリデーションしない場合があります。

4. 無制限な資源消費

API リクエストに制限がないと、攻撃者が複数のリクエストを送信したり、リソースをフラッディングしたりすることでサービス拒否（DoS）攻撃を実施できます。またリクエストごとの有料課金を利用している場合は、金銭的な損害を与えることができます。分散型サービス拒否（DDoS）攻撃は過去２年間で大きく増加し、60%も増加しています。

攻撃ベクター：API は、相互作用を制限していない API に対して複数の同時リクエストを送信することで、悪用される可能性があります。

セキュリティ上の弱点：API ではしばしば、実行タイムアウトや最大許容メモリ、クライアントリクエストの操作回数、サードパーティの支出制限の実装などの活動を制限していません。ロギングを行っても、初期段階で悪意のある活動が知らぬ間に行われていることになりかねません。

5. 機能レベルの認可の不備

機能レベルの権限で管理用エンドポイントにアクセスできるようになると、機密性の高いアクションを実行できるようになります。

攻撃ベクター：攻撃者は、アクセス方法がより構造化され予測可能であるため、API の欠陥を発見し、アクセスできないはずのエンドポイントに正規の API コールを送り込むことができます。場合によっては、エンドポイントの URL を推測し、文字列の「users」を「admins」に変更するような簡単な作業で済むケースさえあります。

セキュリティの弱点：最近のアプリケーションには、たくさんのロール、グループ、複雑なユーザー階層があります。ユーザーは、異なるエリアやオブジェクトに対して異なるロールを持つことがあるため、監視することが困難な場合があります。

6. サーバーサイドリクエストフォージェリー

サーバーサイドリクエストフォージェリー（SSRF）は、ユーザーが提供するURLを最初に検証しないまま API がリモートリソースを取得する場合に発生する可能性があります。サーバーは、悪意のある活動を隠すためのプロキシとして使用されることがあります。研究者は最近、このような SSRF の脆弱性をAzure API 管理で４件発見し、その後パッチが適用されました。

攻撃ベクター：攻撃者は、ユニバーサルリソース識別子（URI）を受信する API エンドポイントを見つけ、アプリケーションに予期しない宛先へのリクエストを送信させます。宛先がファイアウォールや VPN で保護されている場合でも同様です。

セキュリティ上の弱点：アプリケーション開発では、クライアントが提供する URI にアクセスすることが多く、サーバーサイドのデータ取得は一般的にログや監視の対象にはなりません。

7. セキュリティの設定不備

API スタックのセキュリティを強化することは、開発者にとって最優先事項であるべきですが、クラウドサービス全体において、パーミッションの適用が不適切であったり、一貫性がなかったりすることがよくあります。また、セキュリティパッチやソフトウェアが古くなっているケースもあります。企業がクラウドリソースを適切に保護しなかった著名な事例がいくつかあります。アメリカ陸軍情報保全コマンドのインスタンスもその一つです。このときは、保護されていなかったデータのなかに最高機密として分類されるファイルも含まれていました。

攻撃ベクター：脅威者は、パッチが適用されていない欠陥や保護されていないファイルおよびディレクトリを積極的に探し出し、一般的なエンドポイントを攻撃してシステムをマッピングし、不正にアクセスします。リクエストの扱いや処理方法に不一致があると、攻撃ベクトルは未解決のままとなってしまいます。

セキュリティの弱点：設定ミスは、ネットワークからアプリケーションまで、あらゆるレベルで起こり得ます。レガシーオプションや不要なサービスも、さらなる攻撃経路を生み出す可能性があります。

8. 自動化された脅威からの保護の不足

サイバー犯罪者やその他の脅威者は、戦術をますます進化させており、API は格好の標的となっています。自動化は安価で、ダークウェブで広く入手可能です。API 自体に欠陥やバグがなくても、その根底にあるビジネスフローは過剰な活動に対して脆弱である可能性があります。

攻撃ベクター：攻撃者は API モデルやビジネスフローを学習し、自動化ツールを使ってそれを悪用します。たとえば、自動化ツールやボットネットを使用すれば、リクエストを IP アドレスに分散させ、レート制限を回避できます。

セキュリティの弱点：難しいのは、各リクエストが正当なものに見えるため、攻撃として識別されないという点です。しかし、このような自動化された攻撃は、システムをパンクさせ、正当なユーザーのアクセスを妨げる可能性があります。

9. 不適切な資産管理

アプリケーション間の API は、非常に複雑で相互に絡み合っています。サードパーティとの接続は脅威を増大させ、多くの場合、管理されていない複数のバージョンの API が実行されたままになることがあります。古い文書や欠落した文書があると、すべてを追跡できなくなります。

攻撃ベクター：攻撃者は、古いバージョンの API やパッチが適用されていないエンドポイントにアクセスする可能性があります。また、サードパーティを経由してアクセスする可能性もあります。

セキュリティの弱点：インベントリや資産管理の欠如は、パッチが適用されていないシステムをはじめとするさまざmな問題を引き起こす可能性があります。API ホストは、多くの場合、アプリケーションを独立させるマイクロサービスを通じて公開されることがあります。API を導入、管理、引退させるための体系的で文書化された方法の欠如は、さまざまなセキュリティ上の弱点につながる可能性があります。

10. 安全でない API の消費

よく知っているサードパーティやサプライヤーと連携する場合、一般的に受け取るデータを信頼することができ、それほど厳しくないセキュリティ基準を採用する可能性があります。しかし、脅威者がサードパーティを侵害することができれば、API を通じてあなたの社に損害を与えることができるかもしれません。今日、データ侵害の半数が、サードパーティとの接続が原因で発生しています。

攻撃ベクター：API のセキュリティ上の欠陥が悪用されるのは、開発者が API と相互作用するエンドポイントを信頼し、検証や完全な保護を行っていない場合です。たとえば、リソースに適切な制限を加えたり、リダイレクトを検証したり、API からのデータ要求を処理する前に検証 / サニタイズしたりしない、といったケースです。

セキュリティの弱点：API 統合に弱いセキュリティモデルが適用されると、特にトランスポートセキュリティ、入力検証、データ検証、認証、認可などの分野でセキュリティの弱点が生じることがよくあります。これにより、組織は不正アクセスや悪意のあるインジェクションにさらされることになります。