ソース：

訳：

私はソースコードのレビューから始めて、一連の JavaScript ファイルを確認し、最終的に次のように、開発者がサーバーではなくアプリケーションが特定のアクションを実行した後にユーザーをリダイレクトすることを許可しているため、 Open Redirect + XSS に対して脆弱であると思われる 2 つのエンドポイントを発見して。

テスト

最初にオープンリダイレクトを取得しようとしましたが、サーバーは 404他のドメインまたはペイロードが見つかった場合のページ continue_urlパラメータ。
サーバー環境が Java であることと、パラメータ汚染で Java が人気があることはすでに知っていて。
そこで、同じパラメータを2回追加してみました ?continue_url=redacted.com&continue_url=attacker.com
それを検証するために、驚いたことに、サーバーは URI の最初のパラメーターのみをチェックし、ペイロードの影響を受ける 2 番目のパラメーターを無視して。
これにより、サーバーの制限が単にバイパスされ、結果としてリダイレクトされ。 attacker.com、でもどうやって？巻き戻してみましょう。

その時点では、私も少し混乱していましたが、もしあなたと JavaScript が交差したことがあるなら、すでに JavaScript に何か問題があることに気づいているかもしれず。 get_param(param)関数。興味深いですね。
私が言えるのは、開発者が類似した名前の複数のパラメータを処理する Java の動作を十分に認識していないか、関数を作成する際にこの問題を考慮しなかったかのどちらか。
したがって、関数はパラメータの値 (のみ) を重複したエントリで単純に上書きし。

関数から取得した上記のコードは、単にキーを書き換えて。 continue_url同じパラメータのエントリが複数ある場合、の古い値と新しい値。
したがって、指定したパラメーターを使用して上記のコード行をデバッグすると、次のようになり。

したがって、params オブジェクトには最終的に次のキー/値が含まれ。

XSS を取得してユーザー情報を盗む

サーバーの事故のコツを掴んだ後、私は最終的にこの問題を XSS にエスカレートし、その値を JavaScript ペイロードに置き換えようと。
?continue_url=redacted.com&continue_url=javascript:alert(1)

しかし残念なことに、サーバーは 400 Bad Request エラーを返し。

それで、遊んだ後、 continue_urlパラメータ汚染によって 404 エラーを回避した後でも、サーバーにはまだ少しのセキュリティが残っており、パラメータに関連するキーワードをチェックしていることがわかり。
javascriptエラーで応答を制限します 400 。

そこで、次のようなテストケースを思いつきました。

これらのテストケースを検討した結果、サーバーは 考えられるJavaScript XSS 攻撃を防ぐために、正規表現を使用してパラメータ文字列からキーワードを抽出して照合しているという結論に達して。
しかし、この制限を回避する簡単な方法があり。
それは、urlencode されたタブ文字を入れることで。
%09 ペイロード内では単にサーバーの検証を破るのに対し、JavaScript はタブ文字を完全に無視するため、アラートがポップアップ表示され。したがって、私が使用した最終的なペイロードは次のとおりで。