THM学習 Jr Penetration Tester #7 IDOR
nanacomi
Webアプリケーションにおけるアクセス制御の欠陥 = IDOR（Insecure Direct Object Reference）
IDORの仕組み・検出方法・悪用方法について学習するRoom。
nanacomiIDORとは
IDORは、サーバー側で適切なアクセス制御チェックを行わずに、ユーザー入力を信頼してオブジェクト（ファイル、プロフィール、注文情報など）にアクセスを許す脆弱性。
発生例：
- GET /profile/1001 で自分の情報を表示
- 他のユーザーのID（例：1002）に変更して GET /profile/1002 にアクセスすると、相手の情報が表示されてしまう
このようなケースでは、オブジェクトがリクエストを送信してきたユーザーに本当に属しているかをサーバーがチェックしていない。
nanacomiエンコードされたIDからIDORを見つける
多くのWebアプリケーションは、IDを直接見せる代わりにBase64でエンコードして隠すことがある。
例：GET /download?file=MTIz → 123 をBase64で表現した文字列。
このような文字列は a-zA-Z0-9= の文字で構成されていることが多く、簡単に判別可能。
一度Base64デコードして中身を確認し、他のユーザーのIDに変更して再エンコード → 差し替えて送信することで、IDORが成立することがある。
nanacomiより複雑な例では、IDがMD5などのハッシュでマスクされている場合がある。
例：ID 123 → MD5ハッシュ 202cb962ac59075b964b07152d234b70
このパターンでも、もし対象が単純な整数値のハッシュで、ハッシュ化手法が分かれば、値の推測が可能。
実際のアプリがどうハッシュを使っているか、挙動をよく観察する必要がある。
nanacomi予測不可能なIDでのIDOR確認方法
Base64やMD5などのエンコード・ハッシュが使われていない、または意味が不明なIDの場合は、2つのアカウントを作成して比較するのが有効。
- ユーザーAとユーザーB、2つのアカウントを作成
- ユーザーAでログインし、リクエストで使われているIDを記録
- ログアウトして、ユーザーBでログイン
- リクエスト内のIDをユーザーAのIDに差し替えて再送信
- 他人の情報が表示されれば、IDORが存在
ログイン状態に依存せず、IDだけでアクセスが制御されていないケースでは、重大なアクセス制御の欠陥といえる。