Hello there, ('ω')ノ
オープンリダイレクトからリフレクト XSS への手動による移行を。
脆弱性：
オープンリダイレクト
反映された XSS
記事：
https://medium.com/@rodricbr/from-open-redirect-to-reflected-xss-manually-64e633a3d23f
オープンリダイレクトの脆弱性は、アプリケーションが安全でない方法で
ユーザ制御可能なデータをリダイレクトのターゲットに組み込む場合に発生して。
攻撃者は、アプリケーション内で任意の外部ドメインへのリダイレクトを
引き起こす URL を構築する可能性があり。
この動作を利用して、アプリケーションのユーザに対するフィッシング攻撃を
容易にすることができて。
クロスサイト スクリプティング (XSS) とは、リクエストの一部としてユーザが
提供した入力の一部またはすべてを含むユーザ入力が、
Web アプリケーションによってエラー メッセージ、検索結果、
またはその他の応答として即座に返され、そのデータが返されない場合に発生して。
ユーザが提供したデータを永続的に保存することなく、
ブラウザで安全にレンダリングできるようになって。
脆弱なパラメータを見つけた方法：
「開発ツール」の「ネットワーク」タブを使用してサイトに対して
行われたリクエストを分析しているときに、ページをリロードしたところ、
アプリケーションによって奇妙な .js (Javascript) ファイルが
呼び出されていることに気付き。
4 つの Javascript ファイルが連続して (次々に) 呼び出されていることに気づき。
そのため、そのようなファイルを調査することに。
名前は「0.js」、「5.js」、「4.js」などで。
ファイル「5.js」にアクセスしようとすると、ステータス コード 404 が
返されましたが、ファイル「0.js」、「4.js」... はステータス コード 200 を
返していたため、読み取ることができて。
JavaScript ファイルを手動で数分間分析した後、
「0.js」ファイルで次のことに気付き。
アプリケーションには、次のような href 値を受け取るパラメータがあり。
window.location.href(“?url=”);
「url」というパラメータがあることに気づいたとき、
リクエストがアプリケーションに送信されるときに、このパラメータを使用して
外部サイトにリダイレクトできることがすぐにわかり。
その後すぐにそれをテストして。
概念実証 (PoC)：
ルート ディレクトリ「/」の後に、先ほど見つけたパラメータ (url) を追加し、
このパラメータの値として URL を含めると次のようになり。
https://redacted.com/?url=https://www.google.com/
驚いたことに、何も起こらず。
そして、数時間前に同じサブドメインを分析していたときに、
テストしていた特定のパラメータの値に特定の文字が含まれていると
違いが生じることに気づいたことを思い出し。
そこで文字フィルタを手動でバイパスしようと試み始め、
数分後に次のペイロードを使用して。
?url=https://www.google.com/%3C--//#/
文字フィルタを回避することができて。
URL をロードすると、www.google.com にリダイレクトされ。
これは、「url」パラメータがオープン リダイレクトに対して
脆弱であることを意味して。
URL パラメータ自体の後に http プロトコルを含む URL を
呼び出すことができるため、アプリケーションの別の部分で一緒に探していた
友人 (ferreiraklet) が XSS、「javascript:」属性を呼び出して、内容をすべて実行し。
Javascript のコロン (:) の後、反映された XSS ペイロードは次のようになって。
?url=javascript:confirm(document.domain)%3C--//#/
このようにして、Javascript ファイルの分析中に脆弱なパラメータを手動で見つけ
次に Open Redirect の脆弱性を見つけて、それを Reflected XSS に
エスカレーションすることができて。
Best regards, (^^ゞ
