Shikata Ga Nai

Private? There is no such things.

Lab: Exploiting an API endpoint using documentation

Web Security Academy API testing

Hello there, ('ω')ノ

概要（ラボの目的と達成条件）

このラボは、公開された API ドキュメントが攻撃者にどれほど危険かを学ぶ入門レベルの演習です。 目的は API ドキュメントの露出を悪用して、ユーザー carlos を削除すること です。 攻撃者としてログイン可能なアカウント（wiener:peter）が提供されており、この権限を手掛かりに API エンドポイントを探索します。

攻撃者の全体的思考（高レベル）

攻撃者として最初に考えるべきは、アプリが内部でどのような API を呼んでいるかです。フロントエンドが API を叩く形式の場合、ブラウザや Burp Proxy で簡単に観察できます。

今回は、通常ユーザー用の PATCH /api/user/wiener のようなリクエストを手掛かりにして、

  • パスを段階的に短くすることで、API の深部やドキュメントにアクセスできる可能性
  • API のエントリポイントや OpenAPI 仕様がそのまま公開されている可能性

を探ります。

攻撃者は「もし /api/user/{id} が動くなら、/api は何か返すのでは？」という発想で階層を遡ります。 これが API エンドポイントのブルートフォース的探索 であり、実際の攻撃でもよく使われる技術です。

前提（入力、想定される SQL や処理）

アプリは以下のような REST API を実装していると推定されます。

  • PATCH /api/user/{username} → ログインユーザー情報の変更

  • 親ディレクトリを辿っていくと：

    • /api/user：ユーザー識別子が必要
    • /api：API ドキュメント（OpenAPI / Swagger UI）が返ってくる

一般的に、開発者は Swagger UI を開発環境にだけ公開したつもりでも、誤って本番環境にも残してしまう事があります。 攻撃者はそこを突きます。

ステップバイステップ（詳細ハンズオン）

1. ログインして正常な API 呼び出しを観察する

操作：wiener:peter でログインし、メールアドレスを更新する。 目的：アプリが裏で API をどう呼んでいるかを観察するため。

メール更新時に、ブラウザは以下のようなリクエストを送ります：

PATCH /api/user/wiener

これは攻撃の起点となる既知の有効な API URLです。

2. PATCH /api/user/wiener を Burp Repeater へ送る

操作：Proxy → HTTP history → 当該リクエストを右クリック → Send to Repeater 目的：手動でリクエストを編集しながら API の挙動を探るため。

Repeaterで送信すると、ユーザー wiener の情報が返ってくることを確認できます。

3. パスから /wiener を削除する

操作：URL を /api/user に変更 目的：API がユーザー識別子なしでどう反応するか調べるため。

送信すると：

  • 「ユーザー ID がない」エラーが返る → このエンドポイントが 存在していることが分かる（重要）。

4. パスから /user も削除し、/api にする

操作：URL を /api にする 目的：より上位の API ルートを探索し、何が返るか確認するため。

送信すると：

  • API ドキュメント（OpenAPI/Swagger 仕様）が返ってくる

これは重大な露出です。攻撃者が API の全機能を把握できてしまうためです。

5. Swagger UI をブラウザで開く

操作：Repeater のレスポンスを右クリック → Show response in browser 生成された URL をコピーし、Burp のブラウザに貼り付ける。

目的：インタラクティブな API ドキュメントを実際に操作するため。

表示される Swagger UI には、API の一覧が並びます。 ここで攻撃者は DELETE user のエンドポイントを発見します。

6. carlos を削除する

Swagger UI 内の DELETE /user/{username} を選択し：

  • username に carlos
  • Send request

をクリック。

これでユーザー carlos が削除され、ラボが Solved となります。

Burp 操作（具体例）

PATCH リクエストの例

PATCH /api/user/wiener HTTP/1.1
Host: YOUR-LAB-ID.web-security-academy.net
Content-Type: application/json

{"email":"test@example.com"}

パスを短縮した例

PATCH /api/user HTTP/1.1
PATCH /api HTTP/1.1

これらを順に送信して API の挙動を確認します。

レスポンス確認方法（成功のサイン）

  • /api にしたときに OpenAPI JSON または Swagger UI HTML が返る
  • DELETE リクエストを送った後、Swagger UI が 200 OK や "user deleted" を返す
  • ブラウザに戻るとラボが Solved と表示される

トラブルシュート

症状 原因 対策
/api が 404 を返す URL の入力ミス スラッシュの位置を再確認
Swagger UI がうまく開かない Burp で HTTPS 証明書を未インストール Burp 証明書をブラウザに設定
DELETE が失敗する username の入力ミス carlos と正確に入力

防御（開発者向け対策）

API ドキュメントは絶対に本番環境に公開しないこと。

また以下の対策が必要です：

  • Swagger UI / OpenAPI JSON は認証済み開発者のみ参照可能にする
  • 権限チェック（RBAC） を厳密に実装し、一般ユーザーが他人を削除できないようにする
  • API を階層的に辿られても問題がないよう、不要なルートを公開しない
  • 本番環境で開発用エンドポイントを必ず削除する

Best regards, (^^ゞ