APIセキュリティの強化：脆弱性と新たな脅威への対処

はじめに

コネクティビティの高い現代社会では、API（Application Programming Interfaces）がデジタル通信の基盤となり、各種ソフトウェアシステム間のインタラクションを可能にしています。モバイルアプリケーションからクラウドサービスに至るまで、APIはデータやサービスのシームレスなやり取りを促進しているのです。ただしAPIの重要性が高まるにつれ、それに伴うリスクも増えています。API関連のセキュリティ侵害が増加しているため、堅牢なセキュリティ対策の必要性が高まっています。

APIとは？

APIは各種システムを橋渡しして、様々なソフトウェアコンポーネントが互いに通信できるようにします。ソフトウェアやアプリケーションを構築するための一連のプロトコルとツールを提供することで複雑なアプリケーションの作成を可能にします。APIはウェブサービス、モバイルアプリ、IoTデバイスなどが機能するために不可欠なものです。ただしAPIの普及によって攻撃者の標的になる可能性も高くなりました。

APIの主な脆弱性

APIの脆弱性は多岐にわたるため、正しく対処しなければ深刻な侵害につながります。OWASP API Security Top 10によると、最も一般的なAPIの脆弱性には以下があります。

1. BOLA（Broken Object Level Authorization：オブジェクトレベル認証の不備） - APIによるアクセスコントロールが正しく機能しない場合に発生し、攻撃者は本来アクセス権のないデータへのアクセスや変更が可能になります。

2. 認証機能の不備（Broken Authentication） - 認証メカニズムが脆弱な場合に発生し、不正アクセスにつながります。

3. 過剰なデータエクスポージャ（Excessive Data Exposure） - APIが必要以上に多くのデータエクスポージャを行い、機密情報へのアクセスを可能にする場合があります。

4. セキュリティの設定ミス（Security Misconfigurations） - デフォルト設定、不完全または間違った設定によって、APIが攻撃にさらされる場合がります。

5. インジェクション攻撃（Injection Attacks） - 悪意のあるデータをAPIに送信し、SQLインジェクション、コマンドインジェクション、その他のエクスプロイトを誘発することがあります。

6. SSRF（Server-Side Request Forgery：サーバーサイドリクエストフォージェリ） - 攻撃者がAPIを不正に操作可能な状態になり、それをホスティングしているサーバーから意図しない宛先へのリクエストをトリガーさせることができる場合に発生します。

詳細説明：BOLAとBFLAの脆弱性

1. BOLA（Broken Object Level Authorization：オブジェクトレベル認証の不備）

BOLAはAPIセキュリティ分野で最も重大な脆弱性です。APIがユーザーの権限を正しくチェックしなかった場合に発生し、攻撃者が本来アクセス権のないデータへのアクセスや不正操作ができるようになります。  たとえばAPIリクエスト内のIDを変更するだけであるユーザーが別なユーザーのデータにアクセスできる場合、これはBOLAの脆弱性を意味します。

2. BFLA（Broken Function Level Authorization：機能レベル認証の不備）

BFLAはAPIが特定機能へのユーザーアクセス権限を間違って付与した場合に発生します。オブジェクトレベルのアクセスを扱うBOLAとは異なり、BFLAは高度な機能に関係しています。この脆弱性によって正当な権限を持たないユーザーが禁止された操作を実行できるようになるため、深刻な被害を引き起こす可能性があります。

APIの参照と定義

APIの開発および保護の際は、定義、文書化、インタラクションに使用するツールや標準規格について理解しておくことが非常に重要です。ただしケーススタディでも紹介しているように、API文書を公開したままにしておくことは危険です。

以下はAPI文書の自動生成に使用できる一般的な仕様とツールです。

● Swagger

SwaggerはRESTful APIの設計、構築、文書化のための枠組みです。開発者は標準化されたフォーマットでAPIを定義できるため、インタラクティブなAPI文書とクライアントライブラリを簡単に作成することができます。SwaggerのユーザーフレンドリなインタフェースによってAPIとのインタラクションやテストが簡単になります。

● OpenAPI

OAS（OpenAPI Specification）はRESTful APIを定義するための標準規格です。エンドポイント、リクエスト/レスポンスフォーマット、認証方法など、構造化された方法でAPIを記述することができます。SwaggerがベースのOpenAPIはAPI文書の業界標準になっており、異なるAPI間の一貫性を確保し、理解しやすくします。

● WSDL（Web Services Description Language：ウェブサービス記述言語）

WSDLはXMLベースの言語で、SOAPベースサービスなどのウェブサービスを記述するために使用します。サービスが提供する操作、受信/返信するメッセージ、通信に必要な詳細条件を定義します。古いSOAPサービスとの関連性が高いWSDLですが、特定のエンタープライズ環境ではまだ使用されています。

● ASP.NET Web API Help Page

ASP.NET Web API Help PageはASP.NETに内蔵された機能で、APIのヘルプ文書を自動生成してくれます。パラメータの説明やサンプルレスポンスなどAPIエンドポイントの詳細情報を提供することで、開発者はAPIを理解、利用しやすくなります。

● GraphQL Introspection

GraphQL IntrospectionはクライアントがGraphQL APIにスキーマのクエリーを行えるようにする強力な機能です。開発者は使用可能なタイプ、フィールド、操作に関する詳細な情報をAPIから直接入手でき、APIの機能について動的に問い合わせ、理解を深めることができます。

API文書のエクスポージャは危険

API文書は開発者にとって不可欠なものですが、適切にコントロールせずに公開したままにしておくと、不正アクセス、インジェクションにつながる情報漏えいなど、システムが深刻なリスクにさらされることになります。

ケーススタディ：ULTRA REDが脆弱性を自動検出

● CVE-2023-39375：BOLAに関連するこの脆弱性では、間違った認証チェックによって正当な権限のない攻撃者が新しいユーザー管理者を作成することができます。

● CVE-2023-39376：正当な権限のない攻撃者がアプリケーションによるセキュリティ対策を無効化することができるBOLA脆弱性。

● CVE-2024-41702：APIエンドポイント内のSQLインジェクション脆弱性。JSONオブジェクトインジェクションによってサニタイゼーションされていない値がSQLクエリーに渡されてしまいます。

● PII（Personal Identifiable Information：個人を特定可能な情報）のエクスポージャ：攻撃者が他のユーザーのリソースにアクセスできるようになるBFLA脆弱性。特に大企業の社員の情報などが標的となり、PHI（Protected Health Information：保護された健康情報）など、機密性の高いPIIのエクスポージャが発生することがあります。

‍

‍

● ベクタータイプ - SSRF（Server Side Request Forgery：サーバーサイドリクエストフォージェリ）

サマリー：特に反射型の場合、SSRFは深刻な結果をもたらします。弊社ではSSRFを使用してクラウドメタデータをフェッチし、クライアントのクラウド環境にイニシャルアクセスを行うことができました。

検出：前述のAPI定義を自動的に解析し、エンドポイントに脆弱性がないかスキャニングするようにシステムをプログラミングしています。このクライアントの場合は残念なことに脆弱性が放置されたままのAPIリクエストがありました。

この脆弱性により攻撃者はAPIベンダーの信頼できるメールサーバーから他のユーザーにメールメッセージを送信することができたのです。

弊社がSSRFのパラメータをテストするとコールバックが戻ってきました。

しかしそれだけではなく、攻撃者はURLリストを提供して各メールメッセージにファイルを添付することができました。

以下の画像では、リクエストが /api/Email/SendEmail エンドポイントに送信されていることがわかります。これにはAddress、Emails、CCs、BCCsなどのパラメータが含まれています。この例ではInteractshで生成したドメインを使用して、これらのフィールドにプレースホルダーのメールアドレスを入力しました。

SSRFにAWSメタデータエンドポイントなど、一般的で興味深いエンドポイントをいくつか試してみました。AWSメタデータのURL、http://169.254.169.254/latest/meta-dataを添付ファイルとして埋め込みました。

‍

すると‘isSuccess’パラメータがtrueになったため、リクエストが成功しました。

Interactshを使用してファイルの送信をチェックしましたが、一時的なメールも使用することができます。

SMTPインタラクションがあったことがわかります。2番目のSSRFが見付かりました！

verboseモードにするとbase64でエンコードされたコンテンツが確認できます。

エンコードされたデータを復号化してインスタンスメタデータエンドポイントにアクセスできるかどうかを確認します。

‍

自社のAPIを保護

こうした脆弱性を回避するためのベストプラクティスがいくつかあります。

● 強力な認証と認証メカニズムを実装する。

● 最小限の権限によってアクセスを制限するという原則に従う。

● すべての入力内容を検証/サニタイズしてインジェクション攻撃を防止する。

● レート制限と監視によって異常なアクティビティを検出する。

● 定期的にAPIの更新とパッチ適用を行い、既知の脆弱性に対応する。

● スキャニングツール（ULTRA REDなど）を導入して既知/未知の脆弱性を自動検出する。

結論

APIが引き続き拡大する中、その保護が不可欠になっています。一般的なOWASP APIの脆弱性トップ10を理解し、堅牢なセキュリティタウ策を講じることで、企業はデジタルアセットを保護し、自社のAPIのセキュリティを確実に維持することができます。

‍