Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

title: “API の基礎とアタックサーフェスの整理” part: “Part 4” chapter: “4-1”

API の基礎とアタックサーフェスの整理

本章では、REST 形式を中心とした API の構造と、Pentest におけるアタックサーフェス（攻撃面 / Attack Surface）の整理方法を扱う。

本章のゴール

  • 前提：Part 2 の HTTP / JWT / OAuth2 / OIDC の基礎と、Part 3 の Burp Suite を用いたワークフローの概要を把握している。
  • 到達目標：API の基本要素とアタックサーフェスの 3 観点（エンドポイント／データモデル／環境・インフラ）を説明し、OpenAPI 仕様と実トラフィックを使ってテスト対象を整理できる。
  • 対応演習：exercises/crapi/ を対象に Burp Suite で API トラフィックを取得し、OpenAPI 仕様（存在する場合）と照合してエンドポイント一覧とテスト観点を作成する（起動手順は 付録「演習環境クイックスタート」 を参照）。

API の基本要素

典型的な REST API は、次の要素で構成される。

  • エンドポイント（URI）
    例：/api/v1/users/{userId}、/api/v1/orders
  • HTTP メソッド
    GET（取得）、POST（作成）、PUT/PATCH（更新）、DELETE（削除）など
  • リクエストボディ
    JSON や XML で送信されるデータ。ネストしたオブジェクトや配列を含むことが多い。
  • 認証情報
    Authorization ヘッダの Bearer トークン（JWT 等）、API キー、クライアント証明書など。

図4-1 は、クライアント（Web/モバイル）からバックエンド API に到達する境界（Gateway / Load Balancer）と、API が参照する周辺コンポーネント（DB、IdP）をまとめた構成例である。以降は、この図を前提に「誰がどのエンドポイントにアクセスしうるか」を整理した上で、アタックサーフェスを 3 観点に分解する。

図4-1: Web / モバイルと API バックエンドの構成例

flowchart LR
    subgraph Client
        W[Web ブラウザ]
        M[モバイルアプリ]
    end

    subgraph Backend
        GW[API Gateway / Load Balancer]
        API[REST / GraphQL API]
        DB[(Database)]
        IDP[Authorization Server / IdP]
    end

    W --> GW
    M --> GW
    GW --> API
    API --> DB
    API --> IDP

Web アプリケーションの裏側で利用される API もあれば、モバイルアプリや外部パートナー向けに公開される API もある。Pentest では、「誰がどのエンドポイントにアクセスしうるか」を前提条件として整理することが重要になる。

アタックサーフェスの三つの観点

API のアタックサーフェスは、おおむね次の 3 つの観点で整理できる。

  • エンドポイントレベル
    • パス構造（ID やリソースの階層）
    • メソッドごとの機能（読み取り専用か、更新を伴うか）
    • 認証・認可の有無（公開 API / 認証必須 / 管理者専用 など）
  • データモデルレベル
    • リクエストボディ／レスポンスボディのスキーマ（必須・任意のプロパティ）
    • サーバ側で自動バインディングされるオブジェクト（Mass Assignment の有無）
    • ID や外部キーの設計（予測可能性、連番かどうか）
  • 環境・インフラレベル
    • レート制限やスロットリングの設定
    • ログや監査証跡
    • CORS 設定、ゲートウェイや API Management のルール

これらを整理することで、「BOLA の余地があるエンドポイント」「Mass Assignment が発生しうる更新系 API」「レート制限が不足している認証エンドポイント」などの候補を効率的に抽出できる。

OpenAPI / Swagger 仕様の活用

多くの API では、OpenAPI（旧 Swagger）仕様が存在し、次のような形式で公開されている。

  • openapi.json / swagger.json などの JSON 形式
  • 開発者ポータルに掲載された API ドキュメント
  • Swagger UI や Redoc などのブラウザ UI

Pentest では、OpenAPI 仕様を次の用途で活用できる。

  • すべてのエンドポイントとメソッドの一覧化
  • リクエスト／レスポンススキーマから、潜在的な隠しパラメータや不要なフィールドの特定
  • 認証スキーム（securitySchemes）の確認

Burp Suite や他のツール（例：openapi-parser、各種プラグイン）を用いて OpenAPI 仕様を取り込み、テストケースの自動生成やカバレッジ確認に利用することもできる。

クライアントからのトラフィック取得

ブラウザベースの Web アプリケーションだけでなく、モバイルアプリや SPA（Single Page Application）なども API を利用している。これらのトラフィックを取得する方法として、次のようなパターンがある。

  • Burp Proxy を利用した HTTPS トラフィックの中継（証明書インポートが必要）
  • モバイル端末／エミュレータのプロキシ設定と証明書インストール（詳細は Part 5）
  • CLI ツール（curl、httpie など）や Postman からの再現リクエスト

クライアント側の挙動だけに依存せず、「API 仕様と実際のトラフィックを突き合わせること」で、未公開エンドポイントやデバッグ用パラメータなどを見つけられる場合も多い。

次に読む章

本章のポイント

  • API の基本要素（エンドポイント、メソッド、ボディ、認証情報）を整理し、「誰がどのエンドポイントにアクセスしうるか」を前提条件として明確化する。
  • アタックサーフェスは、エンドポイント／データモデル／環境・インフラの 3 観点で整理すると、BOLA や Mass Assignment、レート制限不備などの候補を抽出しやすい。
  • OpenAPI / Swagger 仕様と実トラフィックの両方を活用し、網羅性（カバレッジ）と実装差分の観点からテストケースを組み立てる。