ソース：
訳：
約 2 か月前、ログイン ポータルで永続的な自己 XSS を発見しました。
ほとんどのプログラムは自己 XSS レポートを受け入れませんが、私はログイン CSRF と連携することでこれをログイン ページ上の永続 XSS にエスカレートし、有効な脆弱性としてプログラムに報告しました。
もう一度言いますが、これは私がプライベート プログラムで発見したものなので、redacted.com と呼ぶことにして。
アカウント ポータル ページでは、姓、名などのアカウントの設定を変更できます。
時間をかけて、可能な限りすべてのパラメーターをいじり。
その結果、バックエンドでは名と姓の検証が行われていないことがわかって。
つまり、名前を次のように変更できることを意味します。 <em>John</em>。
しかし、 <script>フロントエンドとバックエンドの間にクラウドフレアがあり、アカウントページに反映される名前もフィルタリングされたため、タグまたは共通XSSペイロードは許可されませんでした。 <に逃げられた <.
このアカウント ポータル ページでバグを探すのは私にとって難しすぎると考え、やめちゃって。
数日後、もう一度試してみようと思い、ブラウザにログイン ページを表示しましたが、フォームに資格情報を入力する前に何か奇妙なことに気づき。
前回は変更した名前でご挨拶していましたが、 John しかしそのHTMLタグは <em>がなくなっていて。
押しました CTRL+Uキーボードでこのページのソース コードを画面に表示すると、名前を囲む HTML タグが表示されました。 濾過されていない。
私は、cloudflare WAF をバイパスする方法について調査を続け。
インターネット上には多くの記事がありましたが、中心となるアイデアは、サーバーのオリジン IP を探すことで。
最も簡単で簡単な方法は、viewdns.org で IP 履歴を探すことです。
Web サイトが最初に Cloudflare なしで設定された場合、発信元 IP がインターネット履歴に記録され。
幸運なことに、viewdns.org に記録されている発信元 IP を見つけました。
発信元 IP から Web サイトにアクセスして、名前を に変更してみました。 <script>alert(\”Are you hungry?\”)</script>、Cloudflare WAF が関与せずにバックエンドにパスが渡されました。
予想どおり、ログイン ページにアクセスすると、アラート ボックスが表示され。
ログイン ページで self-XSS を見つけました。
ほとんどのプログラムは、この種の脆弱性レポートは通常セキュリティ上の脅威を引き起こさないため受け入れませんが、私はこれにあまりにも多くの時間を費やしてしまったので、後戻りする方法はありませんでした。
あとは上がるだけだ！ (エスカレートするという意味です)
自己 XSS (開発コンソールに javascipt コードを配置していないもの) を見つけた場合は、常にそれを他の脆弱性と連鎖させてみてくださ。
エスカレートする自己 XSS について書いた、多くの優れた人々による記事がたくさんあり。
私の状況に関連すると思われるのは、ログイン CSRF と自己 XSS です。
私のペイロードがログインページにどのように保存されるかを見てみましょう。
1.) ログイン後、ユーザーが [Remember me] ボックスにチェックを入れると、セッションは rememberme という名前の Cookie に保存され、有効期限は 1 年に設定されます。
2.) ユーザーがログイン ページに再度アクセスすると、ログアウトしていなくても、ログイン ページに反映された名で挨拶が表示されます。
したがって、ログイン CSRF を見つけることができれば、他のユーザーに私のアカウントへのログインを強制することができ、そのユーザーが再度ログイン ページにアクセスすると、私の XSS ペイロードが実行されます。
ログインリクエストを確認するために Burp Suite から開始し。
予想どおり、ログインリクエスト中に CSRF トークンが認証情報とともに送信され。
そのトークンを削除してリクエストを再送信しようとしましたが、残念ながら失敗し。
何度も言いましたが、諦めるわけにはいきませんでした。
貧乏人CSRFについて聞いたことがありますか?
通常、反 CSRF システムを実装するには、CSRF トークンを、そのアクションを実行する人物を識別するために使用できるものに結び付ける必要があります。
CSRF トークンがユーザーのセッションに関連付けられていない場合、攻撃者は Web サイトから有効な CSRF トークンを取得し、被害者でそれを再利用する可能性があり。
このオプションを試し、別のブラウザ セッションから CSRF トークンをコピーして再利用して。
アカウントにログインできました。 ユーザーログインページでXSSを強制する方法をついに見つけ。
この一連の脆弱性を悪用するために使用した概念実証コードは次のとおりで。
ユーザーが私のページにアクセスすると、私のアカウントへのログインが強制され、次にログイン ページにアクセスすると、私の XSS ペイロードで挨拶されることになり。
ほなほな。
