Hello there, ('ω')ノ
■ 概要（この文書で何を学べるか）
このラボでは、 2FA（多要素認証）の “実装ミス” により、本来必要な 2FA コードを持っていなくてもユーザのアカウントへアクセスできてしまう脆弱性 を学びます。
ポイントは次の通り：
- 2FA 本体ではなく 遷移先 URL のアクセス制御が不十分
- 2FAコード入力画面をスキップしてもサーバ側が拒否しない
- そのため /my-account に直接アクセスするとログイン後扱いになる
■ 前提知識
- 2FA の正しい設計 → 「2FAが完了するまでアカウントページにアクセスできない」のが本来の仕様
- 認可（Authorization）チェックの重要性 → 単にログイン成功だけでなく、2FA完了フラグの検証が必須
- URL 直アクセスでのテスト → Web脆弱性診断では “特定URLに直接アクセスしてみる” は必須の確認項目です
■ なぜこの手順で攻撃が成立するのか（攻撃者の視点）
2FA はユーザ入力を求めるが、アカウントページへのアクセス制御が甘い
サーバ側は
- ログイン成功状態（セッション発行済み）
- 2FA未完了 を区別せず、/my-account のアクセスに対して 2FAチェックを行っていない
つまり ログイン直後に URL を手で /my-account に変えれば 2FA の完全スキップが成立する
ラボではこれを悪用し、被害者のアカウントへ不正に侵入することが可能
■ 実際の手順（1 アクションずつ丁寧に理由付きで解説）
※ “攻撃者はどう考えるか？” を初心者でも完全に理解できるように説明しています。
ステップ 1 — 自分のアカウントで 2FA の動作を観察
- あなた自身のアカウント（wiener:peter）でログイン
- 2FA入力画面が表示される
- 「Email client」から 2FAコードが届くことを確認
- /my-account の URL を控えておく（例：
https://<LAB-ID>/my-account）
なぜ？ → 攻撃時に「2FAをスキップして直接アクセスするURL」を把握しておく必要があるため。
ステップ 2 — 被害者アカウントでログインし、2FA画面まで進める
- ログアウト
- 次に carlos:montoya でログイン
- 2FAコード入力画面へ進む（もちろんコードは持っていない）
なぜ？ → ここですぐにバイパスを試す。この画面は「2FA未完了の段階」にあることを示す。
ステップ 3 — URL を手動で /my-account に書き換える（バイパス）
2FAコード入力画面で、ブラウザの URL を次に書き換える：
https://<LAB-ID>.web-security-academy.net/my-account
Enter キーを押すだけで次のようになる：
- 2FA チェックを通過する
- Carlos のアカウントページが表示される
- Lab solved
なぜ成功する？（攻撃者の視点）
- ログイン直後にセッションIDはすでにブラウザにセットされている
- 2FA完了フラグをサーバが確認していない
- /my-account にアクセスしたとき → サーバは “ログイン済みユーザとして扱ってしまう”
- 結果、2FA が完全に無視される
■ この脆弱性の危険性（なぜ重大か）
2FA は「パスワード漏洩時の最後の砦」ですが、実装が不完全だと完全に無意味になります。
攻撃者は：
- パスワードを何らかの方法で入手
- 2FA 画面に誘導されても
- URL直アクセスで認証フローをすり抜ける
これにより、ユーザ本人が 2FAコードを保持していても アカウントが奪われる。
■ どう防ぐべきか（実務的な防御）
サーバ側で必ず「2FA完了フラグ」を確認すること。
- /my-account のような保護領域は 2FA 未完了なら必ず /login2 にリダイレクト させる
- URL を直接書き換えてもアクセスできない仕組みにする
- ログイン後セッションと、2FA完了後セッションを区別する
- 2FA未完了状態では “閲覧できるページをゼロにする”
■ まとめ（ワンフレーズ）
2FA画面で止まっていても、アカウントページへのアクセス制御が甘いと URL を書き換えるだけで 2FA を完全にバイパスできる。
Best regards, (^^ゞ
