ソース：
脆弱性：OTP, 2FA
訳：
CAPTCHA や 2FA ページなどの認証パラメーターをバイパスするための応答操作テクニックを勉強していたとき、実際のサイトで練習するのが好きなので、練習していたサイトが(mysite[.]com としましょう) で、ほとんどの認証ページ入力に対する JSON 応答を受信して。
そのため、2FA を見たとき、サイトでは 2FA ページにレート制限や最大試行回数が設定されていなかったため、最初に総当たり攻撃を試してみようと思いましたが、サイトがリクエストを暗号化して送信していることがわかり。
そこで、OTP の再利用 (被害者のログイン用に攻撃者アカウントに送信された OTP コードを使用) を考えましたが、これもうまくいかず。
しかし、偽の OTP を入力した後の応答本文で何かを見つけ。
つまり、OTP 検証 API からの応答に応じて、サイトがその人を入場させるかどうかを決定し。
そこで私は次のように考え、正しい OTP の共鳴本体をキャプチャして、それを間違った OTP 応答の代わりに配置できれば、うまくいくかも。
しかし、そうではありませんでした:(
今、ちょっとした問題に直面しています。
応答には、「CallBackPage」というフィールドのパラメータとしてトークンが含まれていました: 「mysite.com/login/landingpage?tk=<some token>」
問題は、トークンが 1 回限りの使用であり、ログイン後にサーバーによって破棄されてしまうことで。
2FA ページをバイパスするには新しいトークンが必要なので、新しいアカウントを作成し、「攻撃者」としましょう。
次に、このアカウントの 2FA を有効にし、そのアカウントでログインすると、サイトから私の電子メールに OTP が送信され、次のように入力しました。
2FA ページ内で応答をインターセプトし、そこからトークンをコピーしてから応答をドロップしたため、サーバーは私のトークンを破棄できなくなり、新しいトークンが得られ。
被害者のアカウントにログインしようとし、2FA ページに乱数を入力してから応答を傍受し、有効な応答の本文に置き換えましたが、今度は有効なトークンに置き換え。
そして、私たちはそれをバイパスし。
ほなほな。
