conducting-api-security-testing

API セキュリティテストの実施

使用する場面

• API エンドポイントの認可の不備、インジェクションの脆弱性、ビジネスロジックの回避をテストする場合
• API が主な通信手段となっているマイクロサービスアーキテクチャのセキュリティを評価する場合
• API ゲートウェイの保護機能（レート制限、認証、入力検証）が適切に適用されていることを検証する場合
• データ漏えいや安全でない設定がないか、サードパーティ API との統合をテストする場合
• イントロスペクションによる情報開示、クエリ複雑度攻撃、認可回避について GraphQL API を評価する場合

使用しないでください：書面による許可を得ていない API、対象範囲として明示的に含まれていない負荷テストやサービス拒否テスト、または安全対策なしで実際の金融取引を処理する本番 API に対しては使用しないでください。

前提条件

• API ドキュメント（OpenAPI/Swagger、GraphQL スキーマ、Postman コレクション）、または API をリバースエンジニアリングするためのアプリケーションへのアクセス
• JSON/XML コンテンツタイプの処理を設定し、API トラフィックをインターセプトできる Burp Suite Professional
• 異なる認証コンテキスト間で API リクエストを整理し、再送するための Postman または Insomnia
• 複数の権限レベル（未認証、一般ユーザー、管理者）で有効な API トークンまたは認証情報
• 対象 API のベース URL とバージョン情報

ワークフロー

ステップ 1：API の発見とドキュメント化

API の攻撃対象領域全体をマッピングします。

• API ドキュメントをインポートする：OpenAPI/Swagger の仕様を Postman または Burp Suite に読み込み、すべてのエンドポイント、メソッド、パラメーター、認証要件をカタログ化します
• ドキュメント化されていない API をリバースエンジニアリングする：モバイルアプリまたは Web フロントエンドのプロキシとして Burp Suite を設定し、すべての機能を操作して API 呼び出しを記録します。Burp のサイトマップをエクスポートし、エンドポイント一覧の基準として使用します。
• GraphQL のイントロスペクション：イントロスペクションクエリを送信して、スキーマ全体を特定します。

  {"query": "{__schema{types{name,fields{name,args{name,type{name}}}}}}"}
  

• エンドポイントの列挙：隠れた API バージョン（/api/v1/、/api/v2/、/api/internal/）、デバッグ用エンドポイント（/api/debug、/api/health、/api/metrics）、管理用エンドポイントをファジングします
• 認証メカニズムを文書化する：API が API キー、OAuth 2.0 Bearer トークン、JWT、セッションクッキー、相互 TLS のいずれを使用しているかを特定します

ステップ 2：認証とトークンのテスト

認証メカニズムの弱点をテストします。

• JWT の分析：JWT をデコードし、クレーム（sub、exp、iss、aud、role）を確認します。次の点をテストします。
  • アルゴリズムの混同：alg を none に変更し、署名を削除します
  • 鍵の混同：alg を RS256 から HS256 に変更し、公開鍵で署名します
  • 弱いシークレット：hashcat -m 16500 jwt.txt wordlist.txt を使用して HMAC シークレットを総当たりします
  • トークンの有効期限：トークンが期限切れになり、期限後に使用できないことを確認します
  • クレームの改ざん：role、userId、または permission のクレームを変更して再署名します
• OAuth 2.0 のテスト：redirect_uri の操作、認可コードの再利用、Referer ヘッダーでのトークン漏えい、state パラメーターの欠落（CSRF）を確認します
• API キーのセキュリティ：API キーがエンドポイントごとに検証されるか、失効したキーが直ちに拒否されるか、クエリ文字列内のキーがアクセスログや分析データに記録されるかをテストします

ステップ 3：認可テスト（BOLA/BFLA）

Broken Object Level Authorization（BOLA）と Broken Function Level Authorization（BFLA）をテストします。

• BOLA（IDOR）テスト：ユーザー固有のデータを返すすべてのエンドポイントで、オブジェクト識別子を別のユーザーの識別子に置き換えます。
  • GET /api/users/123/orders -> GET /api/users/456/orders
  • 数値 ID、UUID、ユーザー名、メールアドレスでテストします
  • Burp Autorize 拡張機能で自動化します。2 つのセッション（攻撃者と被害者）を設定し、すべてのリクエストを再送信します
• BFLA テスト：権限の低いトークンを使用して、管理者用エンドポイントへのアクセスを試みます。
  • DELETE /api/users/456（管理者のみ削除可能）
  • PUT /api/users/456/role（ロールの変更）
  • GET /api/admin/dashboard（管理パネルのデータ）
• Mass assignment：ドキュメントに記載されていない JSON プロパティを追加して送信します。

  PUT /api/users/123
  {"name": "Test", "role": "admin", "isVerified": true, "balance": 99999}
  

• HTTP メソッドテスト：エンドポイントで GET が機能する場合は、PUT、PATCH、DELETE、OPTIONS を試して、保護されていないメソッドを見つけます

ステップ 4：入力検証とインジェクションのテスト

API 入力にインジェクションや検証の不備がないかテストします。

• API パラメーターの SQL インジェクション：すべてのパラメーター（パス、クエリ、本文、ヘッダー）に SQL インジェクションのペイロードを指定してテストします。JSON API は見落とされがちです。{"username": "admin' OR 1=1--", "password": "test"}
• NoSQL インジェクション：MongoDB バックエンドでは、演算子インジェクションをテストします。{"username": {"$gt": ""}, "password": {"$gt": ""}}
• API 経由の SSRF：URL を受け取るパラメーター（Webhook URL、アバター URL、インポートエンドポイント）に、内部アドレスやクラウドメタデータエンドポイントを指定してテストします
• GraphQL 固有のインジェクション：クエリ深度攻撃、ブルートフォース用のエイリアスベースのバッチ処理、フィールド候補の列挙をテストします
• XML API の XXE：XML を受け付ける API エンドポイントに、外部エンティティ宣言を含む XML コンテンツを送信します
• レート制限の検証：認証エンドポイント、パスワードリセット、OTP 検証に 100 件以上のリクエストを短時間に送信し、ブルートフォース対策をテストします

ステップ 5：データ漏えいとレスポンス分析

API レスポンスで過剰なデータが公開されていないか確認します。

• 詳細すぎるレスポンス：API レスポンスで返されるデータと、UI に表示されるデータを比較します。API は必要以上のフィールド（内部 ID、作成日時、他のユーザーのメールアドレス、ロール情報など）を返すことがよくあります。
• エラーメッセージの分析：不正な入力、無効なトークン、存在しないリソースを送信してエラーを発生させます。エラーメッセージからスタックトレース、データベースクエリ、内部パス、技術情報が漏れていないか確認します。
• ページネーションと列挙：ページネーションされたレスポンス（/api/users?page=1、page=2 など）を順にたどって全レコードを抽出し、列挙が可能かテストします
• GraphQL のデータ漏えい：現在のユーザーのロールでは意図されていないフィールドをクエリします。関連をたどるネストされたクエリをテストし、許可されていないデータにアクセスできないか確認します。
• デバッグエンドポイント：/api/debug、/api/status、/metrics、/health、/.env、/api/swagger.json を確認し、内部情報が公開されていないか調べます

主要な概念

用語	定義
BOLA	Broken Object Level Authorization（OWASP API #1）。リクエストしたユーザーに特定のオブジェクトへのアクセス権限があるかを検証できておらず、IDOR 攻撃を可能にする状態です。
BFLA	Broken Function Level Authorization（OWASP API #5）。管理者または特権ユーザー向けの API 機能へのアクセスを、権限の低いユーザーに対して制限できていない状態です。
マスアサインメント	API がフィルタリングせずにクライアントから提供されたデータを内部オブジェクトのプロパティにバインドし、攻撃者が本来アクセスできないフィールドを変更できる脆弱性です。
GraphQL イントロスペクション	すべての型、フィールド、関連を含む API スキーマ全体を公開する、GraphQL の組み込み機能です。本番環境では無効にする必要があります。
JWT	JSON Web Token。シークレットまたは鍵ペアで署名されたクレームを含む、API 認証に使用される自己完結型のトークン形式です。
レート制限	一定の時間内にクライアントが行える API リクエスト数を制限し、ブルートフォース、列挙、悪用を防ぐための制御です。

ツールとシステム

• Burp Suite Professional：Autorize などの拡張機能を使った自動認可テストを含め、API リクエストの傍受、変更、再送に使用する HTTP プロキシです。
• Postman：エンドポイントのコレクションの整理、テストのスクリプト作成、認証コンテキスト間でのレスポンスの比較に使用する API 開発プラットフォームです。
• GraphQL Voyager：イントロスペクションクエリで取得した GraphQL スキーマを調査するためのビジュアルツールです。
• jwt.io / jwt_tool：認証バイパスのテストに使用する、JWT トークンのデコード、分析、改ざん用ツールです。
• Nuclei：よくある設定ミスや既知の脆弱性を検出するための、API 固有のテンプレートを備えたテンプレートベースのスキャナーです。

よくあるシナリオ

シナリオ：フィンテックのモバイルアプリケーションの API セキュリティ評価

背景：あるフィンテックのスタートアップは、REST API バックエンドを備えたモバイルバンキングアプリケーションを提供しています。API は口座管理、資金振替、請求書支払い、取引履歴を扱います。テスターは Swagger ドキュメントと、一般ユーザーおよび管理者のアカウントを持っています。

アプローチ：

1. Swagger 仕様を Postman にインポートし、12 個のコントローラーにわたる 87 個のエンドポイントコレクションを生成します。
2. /api/v1/accounts/{accountId}/transactions に BOLA があり、認証済みのユーザーなら誰でも任意の口座の取引履歴を閲覧できることを発見します。
3. ユーザー更新エンドポイントでマスアサインメントを発見します。"dailyTransferLimit": 999999 を追加すると、設定済みの振替上限を回避できます。
4. 資金振替エンドポイントにレート制限がなく、スロットリングなしで無制限に振替を試行できることを特定します。
5. JWT トークンの有効期限が 30 日で、リフレッシュトークンのローテーションもないため、長期間にわたるセッションハイジャックが可能であることを発見します。
6. 管理者用エンドポイント /api/v1/admin/users が一般ユーザーのトークンでアクセス可能であることを発見します（BFLA）。
7. CVSS スコアと、API コードレベルでの具体的な修正ガイダンスを添えて、すべての調査結果を報告します。

注意点：

• Swagger に記載されたエンドポイントだけをテストし、記載のない API や廃止予定の API バージョンを見落とす
• 認可バイパスを検出するために、すべての権限レベルのトークンを使って同じエンドポイントをテストしない
• UI に返却フィールドの一部しか表示されない場合に、過剰なデータ露出を検出するためのレスポンスボディの分析を怠る
• ドキュメントに表示されたフィールドしか送信せず、マスアサインメントのテストを怠る

出力形式

## Finding: Broken Object Level Authorization in Transaction History API

**ID**: API-001
**Severity**: Critical (CVSS 9.1)
**Affected Endpoint**: GET /api/v1/accounts/{accountId}/transactions
**OWASP API Category**: API1:2023 - Broken Object Level Authorization

**Description**:
The transaction history endpoint returns all transactions for the specified
account without verifying that the authenticated user owns the account. Any
authenticated user can view the complete transaction history of any account
by substituting the accountId path parameter.

**Proof of Concept**:
1. Authenticate as User A (account ID: ACC-10045)
2. Request: GET /api/v1/accounts/ACC-10046/transactions
   Authorization: Bearer <User_A_token>
3. Response: 200 OK with User B's full transaction history

**Impact**:
Any authenticated user can view the complete financial transaction history of
all 45,000 customer accounts, including amounts, dates, recipients, and
transaction descriptions.

**Remediation**:
Implement server-side authorization check that verifies the authenticated user
owns the requested account before returning data:
  const account = await Account.findById(accountId);
  if (account.userId !== req.user.id) return res.status(403).json({error: "Forbidden"});