# IDOR（Insecure Direct Object Reference）学習・報告用レポート
## 脆弱性概要 脆弱性名：IDOR（Insecure Direct Object Reference） 日本語：安全でない直接オブジェクト参照
IDORとは、WebアプリケーションやAPIがユーザーから指定されたIDや識別子を適切に認可（Authorization）確認せず処理してしまう脆弱性である。ユーザーがURLパラメータやAPIリクエスト内のIDを変更するだけで、本来アクセス権限を持たない他ユーザーの情報やリソースへアクセスできる可能性がある。
今回の検証では、顧客情報取得APIに対してIDパラメータを変更し、別ユーザー情報が取得可能であることを確認した。
## 対象機能 機能：顧客情報取得API
エンドポイント： GET /api/v1/customer?id={id}
パラメータ： id
用途： 指定された顧客IDに紐づくユーザー情報を取得する。
## 脆弱性確認手順 1. Firefox DevToolsのNetworkタブからAPI通信を確認。
2. 以下のリクエストを発見。
GET /api/v1/customer?id=1
3. レスポンスとしてユーザー情報が返却された。
{ "id":1, "username":"adam84", "email":"adam-84@fakemail.thm" }
4. Edit and Resend機能を使用し、idパラメータを変更。
変更前： id=1
変更後： id=3
5. リクエストを再送信。
6. 別ユーザーの情報が取得できることを確認。
## 脆弱性の原因 本来、サーバー側では以下の確認が必要。
Authentication（認証）： 「このユーザーはログインしているか」
Authorization（認可）： 「このユーザーは、このcustomer IDの情報を見る権限があるか」
しかし脆弱な実装では、IDの存在だけを確認し、ユーザーの権限確認を行わず情報を返却してしまう。
正常な処理： ユーザーA → customer id=3取得要求 → サーバー → ユーザーAに権限があるか確認 → 許可
脆弱な処理： ユーザーA → customer id=3取得要求 → サーバー → IDが存在するため情報返却
## 影響 攻撃者が自身のアカウントでログインした状態で、ID値を変更するだけで他ユーザー情報を取得できる可能性がある。
漏洩する可能性がある情報： ・氏名 ・メールアドレス ・住所 ・注文情報 ・アカウント情報 ・内部データ
取得だけではなく、編集・削除機能にも同様の問題がある場合、より重大な影響になる。
## 脆弱性分類 CWE： CWE-639（Authorization Bypass Through User-Controlled Key）
OWASP Top 10： A01: Broken Access Control（アクセス制御の不備）
## 技術的理解 IDORではAuthentication（認証）は正常に動作している場合が多い。
例： Cookie: session=xxxxx
ログイン済みユーザーとして認識される。
問題はAuthorization（認可）。
正常： ユーザーA → customer id=1取得 → サーバー → 権限確認 → 許可
脆弱： ユーザーA → customer id=3取得 → サーバー → IDだけ確認 → 情報返却
## 攻撃者が探すポイント IDORでは、ユーザーが変更可能なIDや識別子を探す。
URLパラメータ： /profile?id=100
/user?id=200
パスパラメータ： /api/user/100
JSON Body： { "user_id":100 }
API： GET /api/orders/5001
共通点： ユーザー側で変更可能な参照値が存在する。
## 対策 1. サーバー側で必ず認可チェックを実装する。
2. ユーザー入力されたIDを信用しない。
3. データ取得時に所有者確認を行う。
例： SELECT * FROM customer WHERE id = requested_id AND owner_id = logged_in_user_id;
4. UUIDなど推測困難なIDを利用する。
ただし、UUID化だけでは根本的対策にはならず、必ず認可処理が必要。
## 使用ツール Firefox Developer Tools： HTTPリクエスト確認、パラメータ変更、レスポンス確認。
Burp Suite： 実際のペネトレーションテストやBug Bountyで標準的に使用される。
主な機能： Proxy：通信を取得する HTTP History：過去の通信を見る Repeater：リクエストを編集して再送する Intruder：パラメータを大量テストする
## IDOR調査の基本手順 1. 通信を確認する。 2. APIやURL内のIDパラメータを探す。 3. ID値を変更する。 4. レスポンスの変化を見る。 5. 権限外の情報取得ができればIDORとして報告する。
## Bug Bounty報告例
タイトル： IDOR allows unauthorized access to customer information via customer ID parameter
概要： The customer API endpoint does not properly validate authorization when accessing customer records. By modifying the id parameter, an authenticated user can access other customers' information.
再現手順： 1. Normal userとしてログイン。 2. 以下へアクセス。 GET /api/v1/customer?id=1 3. idを変更。 GET /api/v1/customer?id=3 4. リクエスト送信。 5. 他ユーザー情報が返却されることを確認。
影響： 認証済みユーザーが権限のない顧客情報へアクセス可能になる。
修正案： リクエストされたcustomer IDに対して、ログインユーザーがアクセス権限を持つかサーバー側で確認する。
## 学習まとめ 今回の演習では、IDOR脆弱性の基本的な発見方法を学習した。
重要なのは、IDORは「ログインを突破する攻撃」ではなく、「正規ユーザーが本来許可されていないデータへアクセスできる問題」という点である。
攻撃者はCookieやパスワードを盗む必要はなく、自分の正規セッションを利用したままIDや参照値を変更することで脆弱性を発見する。
IDORはWebアプリケーション、API、Bug Bountyにおいて非常に重要な脆弱性であり、今後学習するHorizontal Privilege Escalation、API IDOR、Broken Access Controlの基礎となる。