ソース：
脆弱性：RACE Condition、IDOR
訳：
まず、Web サイトでの検証プロセスを理解する必要があります。
新しいアカウントを作成するときは、電子メールと電話番号を確認する必要があり。
電話番号を確認するには、電子メールに送信されたリンクを通じて電話番号を確認する必要があり、そのリンクから OTP を入力でき。
これをわかりやすく説明するために、次のシナリオを使用してみましょう。
私はまず Web サイトを調査し、何度も試行した後、検証プロセスのバグを見つけようとして。
応答時間を利用して同じ OTP を取得することで、競合状態の脆弱性を悪用することができて。
脆弱性が発生した経緯は次のとおりです。
2 つのリクエストを同時に送信してシナリオをシミュレートするには:
- 確実に同時送信するために、別のブラウザを使用し
- 「サーバーはセッションごとに一度に 1 つのリクエストを処理するため」 それぞれが異なるセッションを使用。
- ここで、Burp Suite でグループを作成し、「グループを並行して送信 (最終バイト同期)」を使用して送信することで、2 つのリクエストを同時に送信し。
画像に示すように、競合状態を悪用することで、被害者と攻撃者の両方で同じ OTP 番号を取得することができ。
2 つの異なる番号で同じ OTP を取得し。
ただし、前述したように、検証プロセスを完了するには、電子メールに送信されたリンクを通じて OTP を検証する必要があって。
したがって、OTP を取得するだけでは何の意味もありません。
電子メール検証を回避しようと何度も試みた後、リクエスト本文に「PKID」と呼ばれるパラメータがあることに気づき。
興味深いのは、新しいアカウントを作成するたびにその値が 1 ずつ増加することです。
そこで、シナリオの一部として 2 つのアカウントを作成しま。
1 つは攻撃者として、もう 1 つは被害者として、競合状態を悪用して被害者のモバイル OTP を取得し。
あとは、電子メールに送信されたリンクをバイパスするだけで。
これを行うには、電子メール内のリンクに（攻撃者として）アクセスし、「PKID」パラメータ値を 1 桁大きくまたは小さく、たとえば 5 から 4 または 6 に変更し。
また、OTP パラメータ値も設定して。
攻撃者と被害者の番号で受信したのと同じ OTP に送信し、それらを一致させます。
こうすることで、メール認証と電話認証を回避することができました。
ほなほな。
