Hello there, ('ω')ノ
1. 攻撃チェーン全体像
- SSO認証 → パスワードレスログイン → アカウント乗っ取り
一般的に、SSO環境下でも パスワードレス（Magic Link や One-Time Token）機能が併用される場合があります。 ここに設計上の不備があると、 正規ユーザになりすましてログイン可能となります。
2. バイパス成立までの流れ
ステップ1: パスワードレスログイン機能の挙動確認
- 対象サイトで「ログインリンクを送る」機能などを使う
- SSO経由せず、Magic LinkやTokenで直接ログインできるか確認
チェックするポイント:
- Magic Link URL のパラメータ
https://example.com/login/callback?token=abc123
リクエストヘッダー
- Authorization
- Cookie
- SSO用セッションとパスワードレス用セッションが別管理かどうか
ステップ2: Tokenの再利用・パラメータ改ざん
Magic Linkのトークンやパラメータを取得し
- 他人のアカウントIDをセットして送信する
- リクエストリプレイしても使えるか確認
具体例:
POST /login/callback
Content-Type: application/json
{
"token": "abc123",
"user_id": "victim_user_id"
}
- サーバ側が
user_idを正しく検証せず、トークンのみに依存している場合 → アカウント乗っ取りが成立
ステップ3: SSOバイパス成立確認
- 本来SSOを必要とする機能へアクセスし、 パスワードレスログイン後のセッションでアクセス可能かを確認
3. 攻撃成立条件まとめ
| 項目 | 内容 |
|---|---|
| セッション分離 | SSOセッションとMagic Linkセッションが分離されていないこと |
| トークン再利用 | 使い回し可能、または署名検証不足 |
| ユーザIDバリデーション漏れ | トークンに紐付くuser_idのサーバ側確認不足 |
| ログアウト処理 | Magic Link後にSSOセッションがクリアされない |
4. 検証用チェックリスト
✅ パスワードレスログイン機能確認
- [ ] Magic Link や One-Time Token が使われているか確認
- [ ] Token 有効期限や署名有無確認
- [ ] Tokenを別アカウントIDと組み合わせて再利用可能か
✅ SSO関連確認
- [ ] SSOセッションとMagic Linkセッションの完全分離
- [ ] SSOフローをバイパスして機能利用可能か確認
- [ ] SSOとパスワードレス間でCookieやトークンが混ざっていないか
✅ セキュリティ設定関連
- [ ] TokenにJWTやHMAC署名が含まれているか確認
- [ ] user_idを含むリクエストのサーバ側バリデーション有無
- [ ] Magic Link 使用後のSSOセッション破棄設定
Best regards, (^^ゞ
