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 willin

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） 既知の脆弱性のあるコンポ

脅威エージェント / 攻撃ベクトル セキュリティ弱点 影響 API固有：悪用可能性 容易 普及度 一般的：検出可能性 平均 技術的 深刻：特定のビジネスに依存 この問題を悪用するには、攻撃者が対象APIが統合している他のAPIやサービスを特定し、その後侵害する必要があります。通常、この情報は公に利用可能ではないか、統合されたAPIやサービスが容易に悪用可能ではありません。 開発者は、外部または第三者のAPIとやり取りするエンドポイントを信頼し、検証しない傾向があります。これには、輸送セキュリティ、認証/認可、および入力の検証およびサニタイズに関するより弱いセキュリティ要件が含まれます。攻撃者は、対象APIが統合しているサービス（データソース）を特定し、最終的にはそれらを侵害する必要があります。 影響は、対象APIが引き出したデータをどのように処理するかによって異なります。攻撃が成功すると、権限のないアクターに対して機密情報が露出したり、多種多様なインジェクションまたはサービス妨害が発生する可能性があります。 APIは脆弱ですか？ 開発者は、ユーザー入力よりも第三者APIから受け取ったデータを信頼する傾向があります。これは特によく知られた企業によって提供されるAPIに関して当てはまります。そのため、開発者は入力の検証およびサニタイズに関して、より弱いセキュリティ基準を採用する傾向があります。 APIが脆弱である可能性があるのは以下の場合です： 他のAPIと暗号化されていないチャネルでやり取りしている場合； 他のAPIから収集したデータを適切に検証およびサニタイズせずに処理するか、下流のコンポーネントに渡す場合； リダイレクトを無条件に追跡する場合； 第三者サービスのレスポンスを処理するためのリソース数を制限していない場合； 第三者サービスとの相互作用にタイムアウトを実装していない場合。 攻撃シナリオの例 シナリオ #1 あるAPIは、ユーザーが提供したビジネスアドレスを豊かにするために第三者サービスに依存しています。エンドユーザーがAPIにアドレスを供給すると、それが第三者サービスに送信され、返されたデータがローカルのSQL対応データベースに保存されます。 悪意のあるアクターは、第三者サービスを使用して、自分が作成したビジネスに関連するSQLiペイロードを格納します

脅威エージェント / 攻撃ベクトル セキュリティ弱点 影響 API固有：悪用可能性 容易 普及度 一般的：検出可能性 平均 技術的 中程度：特定のビジネスに依存 脅威エージェントは、古いAPIバージョンやパッチが当てられていないエンドポイントを通じて未承認のアクセスを取得する場合があります。また、一部のケースでは攻撃手段が利用可能です。または、データを共有する理由がない第三者からアクセスされる場合もあります。 古いドキュメントでは脆弱性を見つけることが難しく、修正することが難しくなります。資産の在庫と退役戦略の欠如により、未パッチのシステムで実行され、機密データの漏洩が発生する可能性があります。モダンな概念（例：マイクロサービス、クラウドコンピューティング、K8S）により、不必要にさらされたAPIホストを見つけることが一般的です。シンプルなGoogle Dorking、DNS列挙、またはさまざまな種類のサーバー（ウェブカメラ、ルーター、サーバーなど）をインターネットに接続している専門の検索エンジンを使用することで、攻撃対象を発見できます。 攻撃者は機密データにアクセスしたり、サーバーを乗っ取ったりすることができます。時には異なるAPIバージョンや展開が同じデータベースに接続されて実データを取得することがあります。脅威エージェントは、古いAPIバージョンに存在する廃止されたエンドポイントを利用して管理機能にアクセスしたり、既知の脆弱性を悪用したりすることがあります。 APIは脆弱ですか？ APIと現代のアプリケーションの広がりと接続された性質は新たな課題をもたらします。組織は自身のAPIおよびAPIエンドポイントの理解と可視性だけでなく、APIがデータをどのように外部の第三者と共有または保存しているかについても理解することが重要です。 複数のAPIバージョンを実行する場合、APIプロバイダーからの追加管理リソースが必要であり、攻撃面を広げる可能性があります。 APIには「ドキュメントの盲点」がありますか： APIホストの目的が不明確であり、以下の質問に明確な回答がない場合 APIが実行されている環境（例：本番、ステージング、テスト、開発）はどれですか？ APIにネットワークアクセスを持つべきユーザー（例：公開、内部、パートナー）は誰ですか？ どのAPIバージョンが実

脅威エージェント / 攻撃ベクトル セキュリティ弱点 影響 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固有：悪用可能性 容易 普及度 一般的：検出可能性 容易 技術的 中程度：特定のビジネスに依存 攻撃者はクライアントが提供するURIにアクセスするAPIエンドポイントを見つける必要があります。一般的なSSRF（レスポンスが攻撃者に返される場合）は、攻撃が成功したかどうかのフィードバックがないブラインドSSRFよりも容易に悪用できます。 現代のアプリケーション開発の概念では、開発者にクライアントが提供したURIにアクセスすることが推奨されています。そのようなURIの欠如または不適切な検証は一般的な問題です。問題の検出には定期的なAPIリクエストとレスポンスの分析が必要です。レスポンスが返されない（ブラインドSSRF）場合、脆弱性を検出するにはより多くの労力と創造力が必要です。 成功した悪用は、内部サービスの列挙（例：ポートスキャン）、情報開示、ファイアウォールの回避、またはその他のセキュリティメカニズムに影響を与える可能性があります。一部の場合、DoS攻撃や悪意の活動を隠すためにサーバーがプロキシとして使用されることがあります。 APIは脆弱ですか？ サーバーサイドリクエストフォージェリ（SSRF）の欠陥は、APIがユーザーが提供したURLを検証せずにリモートリソースを取得する場合に発生します。これにより、攻撃者はアプリケーションに対して意図しない宛先にクラフトされたリクエストを送信させることができます。それがファイアウォールやVPNに保護されていてもです。 現代のアプリケーション開発の概念により、SSRFはより一般的であり、より危険になっています。 より一般的な事例 – Webhook、URLからのファイル取得、カスタムSSO、およびURLプレビューに基づいて外部リソースにアクセスすることを開発者が推奨しています。 より危険な事例 – クラウドプロバイダーやKubernetes、Dockerなどの現代の技術は、HTTP経由で管理および制御チャンネルを予測可能で知られているパスで公開します。これらのチャンネルはSSRF攻撃の簡単な標的となります。 また、現代のアプリケーションの接続性のために、アプリケーションからのアウトバウンドトラフィックを制限することがより困難になっています

脅威要因 / 攻撃ベクトル セキュリティ弱点 影響 API固有：悪用可能性 容易 普及度 広範囲：検出可能性 平均的 技術的 中程度：特定のビジネスに依存 悪用は通常、APIに支えられたビジネスモデルを理解し、感度の高いビジネスフローを見つけ、これらのフローへの自動アクセスを行うことに関与します。これにより、ビジネスに害を与える可能性があります。 APIの全体像がないことで、ビジネス要件を十分にサポートできないことがこの問題の広がりに寄与します。攻撃者はターゲットのワークフローに関与するリソース（例：エンドポイント）とそれらがどのように連携して動作するかを手動で特定します。既に対策メカニズムが存在する場合、攻撃者はそれらを回避する方法を見つける必要があります。 一般的な技術的影響は予想されません。悪用はビジネスに異なる方法で害を与える可能性があります。たとえば、正規のユーザーが製品の購入を妨げられたり、ゲーム内経済のインフレを引き起こす可能性があります。 APIは脆弱ですか？ APIエンドポイントを作成する際に重要なのは、それがどのビジネスフローを公開するかを理解することです。一部のビジネスフローは他よりも感度が高く、それらに過剰なアクセスが行われるとビジネスに害を及ぼす可能性があります。 感度の高いビジネスフローとそれに関連する過剰なアクセスのリスクの一般的な例： 製品の購入フロー – 攻撃者は一度に高需要アイテムの在庫をすべて購入し、高い価格で再販する（スケーリング）ことができます コメント/投稿の作成フロー – 攻撃者はシステムにスパムを送り込むことができます 予約の作成 – 攻撃者は利用可能なすべての時間枠を予約し、他のユーザーがシステムを使用するのを妨げることができます 過剰なアクセスのリスクは業界やビジネスによって異なる場合があります。例えば、あるソーシャルネットワークではスクリプトによる投稿の作成がスパムのリスクと見なされるかもしれませんが、別のソーシャルネットワークでは推奨されています。 APIエンドポイントは、適切にアクセスを制限せずに感度の高いビジネスフローを公開している場合に脆弱です。 攻撃シナリオの例 シナリオ #1 技術企業が感謝祭に新しいゲーム機を発売すると発表しました。この製品は非常に高い需要があり

脅威要因 / 攻撃ベクトル セキュリティ弱点 影響 API固有：悪用可能性 容易 普及度 一般的：検出可能性 容易 技術的 深刻：特定のビジネスに依存 攻撃者は、匿名ユーザーまたは通常の権限を持つユーザーとしてアクセスするべきでないAPIエンドポイントに対して正当なAPIコールを送信する必要があります。公開されたエンドポイントは簡単に悪用されます。 関数またはリソースの認可チェックは、通常、構成またはコードレベルで管理されます。適切なチェックの実装は、現代のアプリケーションには多種多様な役割、グループ、複雑なユーザー階層（サブユーザー、複数の役割を持つユーザーなど）が含まれるため、混乱のもとになる場合があります。APIは構造化されており、異なる機能にアクセスすることが予測しやすいため、これらの欠陥を発見することが容易です。 このような欠陥により、攻撃者は認可されていない機能にアクセスできるようになります。管理機能はこの種の攻撃の主要なターゲットであり、データの開示、データの損失、またはデータの破損につながる可能性があります。最終的にはサービスの中断につながる可能性があります。 APIは脆弱ですか？ 壊れた関数レベルの認可問題を見つけるための最良の方法は、認可メカニズムの徹底した分析を行うことです。ユーザー階層、アプリケーション内の異なる役割やグループを考慮しながら、次のような質問をします： 通常のユーザーは管理エンドポイントにアクセスできますか？ ユーザーはHTTPメソッドを単純に変更することで、アクセスすべきでない機敏なアクション（例：作成、変更、削除）を実行できますか？ グループXのユーザーは、単にエンドポイントURLとパラメータを推測することでグループYのユーザーにのみ公開されるべき機能にアクセスできますか（例：/api/v1/users/export_all）？ APIエンドポイントがURLパスに基づいて通常または管理者専用であると仮定しないでください。 開発者が通常、管理エンドポイントのほとんどを特定の相対パス（例：/api/admins）の下に公開することを選択する一方で、これらの管理エンドポイントが通常のエンドポイントと一緒に他の相対パス（例：/api/users）に存在することが非常に一般的です。 攻撃シナリオの例 シナリオ #1 招待されたユーザ

脅威要因 / 攻撃ベクトル セキュリティ弱点 影響 API固有：悪用可能性 平均 普及度 広範：検出可能性 簡単 技術的 深刻：特定のビジネスに依存 悪用には簡単なAPIリクエストが必要です。単一のローカルコンピュータまたはクラウドコンピューティングリソースを使用して、複数の同時リクエストが行われることがあります。トラフィックの高負荷によるDoS攻撃を引き起こすために設計された自動化ツールのほとんどがAPIのサービスレートに影響を与えます。 クライアントの相互作用またはリソース消費を制限しないAPIを見つけるのは一般的です。リクエストのパラメータによってリソースの数を制御するものや、応答のステータス/時間/長さの分析を行うことで問題を特定できます。バッチ処理も同様です。脅威要因はコストの影響を直接見ることができないが、サービスプロバイダ（例：クラウドプロバイダ）のビジネス/価格モデルに基づいてそれを推定できます。 悪用によりリソース枯渇によるDoS攻撃が発生する可能性がありますが、それによりCPU需要が高まり、クラウドストレージの必要性が増加するなど、インフラ関連の運用コストも増加する可能性があります。 APIは脆弱ですか？ APIリクエストを満たすためには、ネットワーク帯域幅、CPU、メモリ、ストレージなどのリソースが必要です。これらの必要なリソースは、API統合を通じてサービスプロバイダによって提供され、リクエストごとに支払われます（例：電子メール/SMS/電話の送信、生体認証の検証など）。 少なくとも次のいずれかの制限が欠落しているか不適切に設定されている場合、APIは脆弱です： 実行タイムアウト 最大割り当て可能メモリ 最大ファイル記述子数 最大プロセス数 最大アップロードファイルサイズ 単一のAPIクライアントリクエストで実行する操作の数（例：GraphQLのバッチ処理） 単一のリクエスト-レスポンスで返すページごとのレコード数 サードパーティサービスプロバイダの支出限度額 攻撃シナリオの例 シナリオ #1 あるソーシャルネットワークはSMS検証を利用した「パスワードを忘れた」フローを実装し、ユーザーがパスワードをリセットするためにSMS経由でワンタイムトークンを受け取れるようにしています。 ユーザーが「パスワードを忘れた」をクリックすると、ユーザーのブ

脅威要因 / 攻撃ベクトル セキュリティ弱点 影響 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 iden