Hello there, ('ω')ノ
IDORがよく発生する場所
- プロフィールページ
- 社内経費システムの明細ページ
- 勤怠システムの打刻履歴
- ファイルダウンロードURL
いずれも「id=」「user_id=」「file_id=」などがURLやリクエスト内に含まれているケースです。
実際のチェック手順① URLで確認する
- 対象システムにログイン
- 自分の情報ページを開く
- URL内に数字や文字列が含まれているか確認：
例： https://intra.example.co.jp/profile?id=123
- id= の数字を変えて再アクセス：
https://intra.example.co.jp/profile?id=124
✅ 他人の情報が見えた場合 → IDORリスク大
実際のチェック手順② APIリクエストで確認する
- F12キー → Networkタブ
- 自分のデータを取得するAPIリクエストを確認：
例：
GET /api/user/info?id=123
- idパラメーターを別の値に変更して再送信
✅ 成功すればIDOR成立 ✅ 403 Forbiddenやエラーになるのが正常な状態
よくあるパラメーター名リスト
- id
- user_id
- file_id
- token
- receipt_id
単純な連番の場合は特に注意が必要です。
実際の社内システムチェック例
- 勤怠打刻履歴
- 経費精算明細
- ダウンロードファイルURL
いずれも「id=」「file_id=」を変更して、データ漏洩がないか確認します。
チェックリストまとめ
- [ ] URL内のidやuser_idを変更して確認したか？
- [ ] APIリクエスト内のidやtokenを変更して再送信したか？
- [ ] エラーや403 Forbiddenが適切に返るか？
- [ ] 連番IDや予測しやすい番号を使っていないか確認したか？
注意事項
- 本番環境でテストする場合は必ず事前許可を取ること
- できればテスト環境やダミーアカウントで実施すること
まとめ
- IDORはシンプルな操作で見つかる脆弱性
- URLやAPIリクエスト内のidやtokenを意図的に変更するだけ
- 他人のデータが見えた時点で重大リスク
Best regards, (^^ゞ
