Broken Access Control (IDOR)

はじめに

安全でない直接オブジェクト参照（Insecure Direct Object References: IDOR）は、アプリケーションがユーザーから提供された入力を利用してオブジェクトに直接アクセスする際に発生する、アクセス制御の脆弱性の一種です。アプリケーションが、そのオブジェクトを要求しているユーザーにアクセス権があるかどうかを適切に検証していない場合、攻撃者は参照（データベースの ID、ファイル名、URL 内のユーザーID など）を操作して、他ユーザーの機密データにアクセスできてしまいます。

重要な点は、参照そのものが脆弱性なのではなく、現在のユーザーがその参照先にアクセスしてよいかをチェックせずに、参照を信頼してしまうことが脆弱性であるという点です。

この実験では、セキュリティテスターとしてローカルの Web アプリケーション API を評価します。まずは標準ユーザーとして認証を行い、アプリケーションがどのようにユーザープロファイルを参照しているかを分析します。その後、IDOR の脆弱性を悪用して、管理者を含む他ユーザーのプライベートデータにアクセスします。

標準ユーザーとしての認証

このステップでは、マシン上のポート 5000 で実行されているローカル Web API と対話します。アプリケーションの脆弱性をテストするために、まずは標準ユーザーとして認証を行い、有効なセッショントークンを取得する必要があります。

今回は、Alice という標準ユーザーの認証情報が提供されています。ユーザー名は alice、パスワードは password123 です。

curl コマンドラインツールを使用して、ログインエンドポイントに HTTP POST リクエストを送信します。curl は、サーバーとの間でデータを転送するための強力なツールです。

ターミナルで以下のコマンドを実行してログインします。

curl -X POST http://localhost:5000/api/login \
  -H "Content-Type: application/json" \
  -d '{"username": "alice", "password": "password123"}'

コマンドの詳細は以下の通りです。

-X POST: POST リクエストを送信することを指定します。これは通常、ログイン情報などのデータを送信する際に使用されます。
-H "Content-Type: application/json": 送信するデータが JSON 形式であることをサーバーに伝えます。
-d '...': ユーザー名とパスワードを含む実際の JSON データペイロードです。

認証情報が正しければ、以下のような出力が表示されます。

{"token": "Bearer alice_token", "user_id": "1001"}

token と user_id を控えておいてください。トークン（Bearer alice_token）はデジタル ID カードとして機能します。今後のリクエストでは、認証済みであることを証明するためにこれを含める必要があります。user_id（1001）は、アプリケーションのデータベース内での一意の識別子です。

オブジェクト参照（URL/API）の分析

Alice として認証されたので、彼女のユーザープロファイルにアクセスできます。多くの Web アプリケーションでは、ユーザープロファイルは、認証トークンと特定のオブジェクト（この場合はユーザープロファイル）への参照を必要とする API エンドポイントを介してアクセスされます。

再度 curl を使用しますが、今回は /api/profile エンドポイントに GET リクエストを送信します。HTTP ヘッダーに認証トークンを含め、URL に user_id を指定する必要があります。

これは実際の API で見られる典型的なパターンです。トークンがセッションの存在を証明し、パラメータが取得するオブジェクトを選択します。安全なアプリケーションでは、これら 2 つの要素を認可チェックで結びつける必要があります。

以下のコマンドを実行して、Alice のプロファイルを表示します。

curl -H "Authorization: Bearer alice_token" \
  "http://localhost:5000/api/profile?user_id=1001"

このコマンドにおいて：

-H "Authorization: Bearer alice_token": デジタル ID カードをサーバーに渡します。
?user_id=1001: URL の末尾に付加されたクエリパラメータです。これが 直接オブジェクト参照 です。サーバーに対し、どのデータベースレコードを取得すべきかを正確に伝えます。

Alice のプロファイル情報を含む JSON レスポンスが返されるはずです。

{"name": "Alice", "role": "user", "email": "alice@example.com", "secret": "alice_secret_123"}

アプリケーションが URL 内の user_id=1001 パラメータに依存して、どのデータを返すかを決定していることに注目してください。安全なアプリケーションであれば、Bearer alice_token に関連付けられたユーザーが、実際に user_id=1001 のデータを閲覧する権限を持っているかを検証するはずです。アプリケーションがこの認可チェックを行っていない場合、IDOR に対して脆弱であると言えます。

ユーザーID の操作

このステップでは、アプリケーションが適切にアクセス制御を強制しているかをテストします。現在 Alice として認証されていますが、他のユーザーのデータをサーバーに要求した場合はどうなるでしょうか。

これが認可における核心的な問いです。「ログインしているか？」と「このオブジェクトを読み取る権限があるか？」は異なるチェックであり、これらを混同することが IDOR に直結します。

Bob という別の標準ユーザーがおり、彼のユーザーID が 1002 であると仮定します。もしアプリケーションが IDOR に対して脆弱であれば、Alice が Bob のプロファイルを閲覧する権限を持っているかを確認することなく、URL 内の user_id パラメータを盲目的に信頼します。

前のコマンドの user_id パラメータを 1001 から 1002 に変更して、以下のコマンドを実行してください。

curl -H "Authorization: Bearer alice_token" \
  "http://localhost:5000/api/profile?user_id=1002"

サーバーから返される出力を見てみましょう。

{"name": "Bob", "role": "user", "email": "bob@example.com", "secret": "bob_secret_456"}

Alice として認証されたまま、Bob のメールアドレスやシークレットキーを含むプライベート情報を取得することに成功しました！

これは、安全でない直接オブジェクト参照（IDOR）の脆弱性が存在することを裏付けています。サーバーは（トークンを検証することで）ログインしていることは確認しましたが、要求された特定のオブジェクト（Bob のプロファイル）にアクセスする権限があるかどうかをチェックしていませんでした。

認可されていないデータへのアクセス

IDOR の脆弱性が確認できたので、攻撃をエスカレートさせて、非常に機密性の高い情報にアクセスしてみましょう。多くのシステムでは、管理者のユーザーID は 1、0、あるいは 9999 のように予測可能な値になっています。

このアプリケーションでは、管理者のユーザーID は 9999 です。同じ IDOR の脆弱性を悪用することで、秘密のフラグが含まれている管理者のプロファイルを抽出してみます。

発見した内容を記録するために、curl コマンドの出力を現在の作業ディレクトリ（~/project）内の flag.txt というファイルにリダイレクトします。

以下のコマンドを実行して、管理者のプロファイルを取得し、保存します。

curl -H "Authorization: Bearer alice_token" \
  "http://localhost:5000/api/profile?user_id=9999" > ~/project/flag.txt

> 記号は、通常画面に表示される出力を指定したファイルにリダイレクトします。

管理者のデータを正常に取得できたことを確認するために、cat コマンドを使用してファイルの内容を読み取ります。

cat ~/project/flag.txt

秘密のフラグを含む管理者のプロファイルデータが表示されるはずです。

{"name": "Admin", "role": "admin", "email": "admin@example.com", "secret": "FLAG{IDOR_VULN_EXPLOITED}"}

おめでとうございます！IDOR の脆弱性を悪用してアクセス制御をバイパスし、機密性の高い管理データを取得することに成功しました。

まとめ

この実験では、重大なアクセス制御の欠陥である「安全でない直接オブジェクト参照（IDOR）」の仕組みを探求しました。まずは標準ユーザーとして認証を行い、アプリケーションが URL パラメータを介してどのようにユーザーデータを参照しているかを分析しました。これらのパラメータを操作することで、認可チェックをバイパスし、他ユーザーのプライベートプロファイルを閲覧することに成功しました。最後に、攻撃をエスカレートさせて機密性の高い管理データを抽出しました。

この演習は、サーバー側で堅牢な認可チェックを実装することの重要性を強調しています。アプリケーションは、オブジェクトへのアクセスを許可する際に、ユーザーから提供された入力のみに依存してはなりません。認証されたユーザーが要求されたリソースにアクセスする明示的な権限を持っているかを、常に検証する必要があります。