Hello there, ('ω')ノ
🔍 よくある問題のパターン：パラメータ改ざんによる部分的な情報漏洩
例：
GET /user/personal-info?user=carlos
- 表面的には自分のアカウントページしか見られないようになっていても、
- このような
userパラメータで他人のデータを指定できる設計だと、 - 「ページ全体は表示されないが、特定の項目だけが他人のデータとして表示される」という事態が発生します。
🧪 脆弱な設計の典型例
/accountにアクセスした際、ログインセッションでユーザーを認識する設計に見える。しかし、APIキーやメールアドレスなどの一部のデータを取得する内部処理で、
GET /user/email?user=carlosGET /user/apikey?user=carlos
- といったように、ユーザー指定がURLやクエリで制御されていると、攻撃者が任意の値に変更できてしまう。
⚠️ このような設計ミスの危険性
| 問題点 | 解説 |
|---|---|
| 部分的なアクセス制御漏れ | 全体のページでは制限されていても、個別のデータ取得APIで抜けがある |
| ロールやセッション確認が未実装 | パラメータだけでユーザーを特定しており、セッションとの照合をしていない |
| IDORと組み合わさる | パラメータ改ざんによる「水平権限昇格」の典型例となる |
👨💻 ペンテスト時のチェックポイント
- アカウントページにアクセスし、Burpなどで全リクエストを確認。
- パラメータに
username、id、emailなどが含まれているかチェック。 - それらの値を他のユーザー名に書き換えてみる。
- 他人のメールアドレスやAPIキーが表示されたら 情報漏洩（IDOR）成立。
🛡 防止策（開発者向け）
| 対策 | 内容 |
|---|---|
| サーバー側でセッションと照合 | req.user.id を使ってログイン中ユーザーのみに限定する |
| クエリやURLでユーザーを指定しない | 常に現在のセッションからユーザーを特定 |
| 一括取得・表示モデルの導入 | ユーザーデータを個別APIではなく一括でセキュアに取得する |
✅ まとめ
- 一見安全に見えるアカウントページでも、一部の情報だけが他人のデータになることがある。
- それはアクセス制御の“部分的な”漏れであり、立派な情報漏洩脆弱性です。
- ペンテストでは、パラメータ変更が効くかどうかを必ず確認しよう。
🔐 「ページは見えないが、データは盗める」――そんな抜け道がある設計は、攻撃者にとってのごちそうです。パラメータベースのユーザー指定には、常に疑いの目を持ちましょう。
Best regards, (^^ゞ
