Shikata Ga Nai

Private? There is no such things.

Bypass Rate Limit — A blank space leads to this random encounter!を訳してみた

Hello there, ('ω')ノ

 

バイパスレート制限 - 空白スペースは、このランダムな遭遇につながるを。

 

脆弱性:

 パスワードリセットの欠陥

 レート制限バイパス

 

記事:

 https://infosecwriteups.com/bypass-rate-limit-a-blank-space-leads-to-this-random-encounter-e18e72fbf228

 

今回は、 「example.com」という名前のウェブサイトについて。

ログイン機能をテストしているときに、パスワードをリセットしてみて。

この機能は、パスワードのリセットを要求すると。

サーバがOTPを自分の電子メールと携帯電話番号に送信するようなもので。

そこに自分の携帯電話番号を追加して。

 

最初は、パスワードリセットリクエストをIntruderに送信し。

nullペイロードを試したり、任意の値を追加したりしましたが。

20リクエスト後にレート制限が有効になっているため、失敗して。

 

そこで、X-Forwarded-Host:127.0.0.1、X-Forwarded-Client、X-Client-IP、および。

どれも機能しなかった他のすべてのヘッダを追加して。

そこで、IPベースではなかったためBurpのIP Rotatedで失敗して。

これは、複数のリージョン間でAPIゲートウェイを簡単に起動できる拡張機能で。

 

 

そこで、%00(メールの最後にヌルバイト)と他のエンコードされた文字を。

追加してみましたが、これらも機能せず。

 

メールの最後にスペースを追加すると、最初は失敗したレート制限を。

回避できる可能性があることを思い出して。

1つのアカウント(携帯番号なし)を作成して。

 

このWebサイトを予約に使用することがあるため。

すでに個人アカウント(電話番号が確認されているアカウント)を持っていて。

下記が、スペースなしのリクエストとレスポンスで。

 

 

 

テストアカウントでずっとテストしていて。

ランダムに個人アカウントを選択し、メールの最後にスペースを追加しましたが。

携帯電話番号が電子メールに関連付けられているため。

最後にスペースがあるためにOTPがメールに送信されないことがわかって。

 

なので、OTPが自分の携帯電話に送信されて。

下記が、スペースを追加した後のリクエストとレスポンスで。

 

 

 

このバグの助けを借りて、レート制限をバイパスし。

被害者の携帯電話番号に巨大なリクエストを送信することができて。

これは大きな脆弱性ではないかもしれませんが。

この種の小さなことがさまざまなシナリオで役立つことを願っていて。

 

Best regards, (^^ゞ