Hello there, ('ω')ノ
▶️ 概要（Not solved）
このラボでは、OAuthを用いた「SNSアカウントでログイン」機能において、クライアント側の検証ミスにより他人のアカウントにログインできてしまう脆弱性を探し、悪用します。
🧪 攻撃手順（Solution）
Burpを使ってProxy越しにログイン
wiener:peterで自分のSNSアカウントを使って、OAuthフローを実行- OAuth認証後、自サイトにリダイレクトされて「My account」ページが表示されることを確認
HTTP履歴を確認
- Burpの「Proxy」→「HTTP history」でOAuthフロー関連のリクエストを確認
/auth?client_id=…→ OAuthサーバーへのリクエスト確認
POST /authenticate をBurp Repeaterへ送信
- クライアントアプリから
/authenticateに送信されたユーザー情報（メールアドレス＋アクセストークン）を取得 - Repeaterにリクエストを送信
- クライアントアプリから
メールアドレスを変更
- Repeaterで
emailフィールドの値をcarlos@carlos-montoya.netに書き換えてリクエストを送信し、エラーにならないことを確認
- Repeaterで
ブラウザでリクエストを再実行
- Repeaterの「Request in browser」→「In original session」を選択
- ブラウザでアクセスすると、Carlosとしてログイン状態になる
ラボ完了
- そのまま「My account」ページにアクセスできれば、ラボは Solved です
✅ 攻撃のポイント
- OAuthフロー自体は正しく動作しているが、クライアントが「戻ってきたメールアドレス」と「トークンの所有者」を正しく照合していない
- この不備により攻撃者は、自分で取得した有効なアクセストークンを使い、それを他人のメールアドレスに関連付けてPOSTすることができてしまう
- ログイン済みである必要はあるが、パスワード不要で他人のアカウントへ切り替え可能という重大な問題が発生する
🛡 改善策／正防御方法
| 対策項目 | 内容 |
|---|---|
| アクセストークンとユーザー情報の照合 | OAuthで得たトークンのユーザーIDと、明示的に照合する。問い合わせ先として /userinfo を使う。 |
| POST /authenticate の入力検証 | "who is this token for?" を明確に確認し、email欄での偽装を防ぐ |
| サーバーサイドのチェック強化 | クライアントベースで安全チェックしてもダメ。サーバーでもメールやIDの所有が一致しているか再確認 |
Best regards, (^^ゞ
