Hello there, ('ω')ノ
🎯 脆弱性の概要
Webアプリケーションは、不正なアクセスを検出すると以下のような動作をします：
HTTP/1.1 302 Found Location: /login
→ これは「ログインページへのリダイレクト」で、未認証または不正ユーザーに対してアクセスを拒否する仕組みです。
しかし、このレスポンス本文に注意してください。
🕵️♂️ 問題の本質：レスポンス本文に機密情報が含まれている
例として、以下のようなレスポンスが返ってきたとします：
HTTP/1.1 302 Found
Location: /login
<html>
<body>
<p>You are being redirected...</p>
<div>User info: carlos@example.com, API Key: abc123xyz</div>
</body>
</html>
→ この場合、たとえリダイレクトされていても、攻撃者はレスポンス本文を通じてターゲットの機密情報を得ることができます。
🧪 典型的な攻撃シナリオ
- 攻撃者が自分のアカウントでログイン。
- Burp Repeater などで
GET /account?id=carlosを実行。 - レスポンスはリダイレクト（302）だが、本文に carlos の情報が含まれている。
- ブラウザではリダイレクトされて見えないが、Burp上では情報が見えてしまう。
- → 攻撃成功！
🛡 開発側の対策
| 対策 | 解説 |
|---|---|
| レスポンス前に認可チェック | ユーザーがアクセス権を持つかどうかを最初に確認すること |
| リダイレクト時は本文を空にする | ヘッダーだけ返す（例：204 No Content など） |
| セッションベースでデータ取得 | パラメータを信用せず、セッションからユーザー情報を特定する |
✅ まとめ
- 表面的にリダイレクトされているからといって安全とは限らない。
- 機密情報は常に「レスポンス本文に含まれていないか」チェックすべし。
- レスポンスの構造をよく観察することがペンテスト成功の鍵。
💡 セキュリティは「見た目」ではなく「挙動」で判断せよ。リダイレクトが起きていても、レスポンスの中身に騙されないことがペネトレーションテスターとしての重要な視点です。
Best regards, (^^ゞ
