web-dev-qa-db-ja.com

OWASP CSRFGuardはXMLHttpRequest経由でトークンを取得します-なぜですか？

レガシーを保護するために CSRFGuardプロジェクト を使用したいJava webappをCSRF攻撃から保護します。公開されている最新のMaven依存関係バージョンは3.1.0で、これを使用しています。

これは、すべての保護されたページに含まれているJavaScriptコードの一部です。

var xhr = window.XMLHttpRequest ? new window.XMLHttpRequest : new window.ActiveXObject("Microsoft.XMLHTTP");
var csrfToken = {};
xhr.open("POST", "/JavaScriptServlet/", false);
xhr.setRequestHeader("FETCH-CSRF-TOKEN", "1");
xhr.send(null);

var token_pair = xhr.responseText;
token_pair = token_pair.split(":");
var token_name = token_pair[0];
var token_value = token_pair[1];

これは、専用のサーブレットによって生成される個別のJSファイルであり、キャッシュヘッダーはありません。

トークンの名前と値が生成されたJavaScriptに直接埋め込まれていない理由がわかりませんが、代わりに同期（！）AJAX呼び出しを介してフェッチされます。

トークンを直接含めるように変更した場合、脆弱性はありますか？

javascriptjavacsrfowasp
3
Michael Böckling

トークンを直接含めるように変更した場合、脆弱性はありますか？

そうそう。

次に、攻撃者はそのスクリプトを自分のページに含めることができます。

<script src="http://yourserver.tld/yourpart"></script>

そして、このコードを実行させます：

var token_name = "sample-token-name";
var token_value = "sample-token-value";

次に両方token_nameおよびtoken_valueは、CSRF攻撃を作成するためにアクセスおよび使用できる攻撃者のページのグローバル変数にはなりません。

トークンを取得するためにAJAX=を使用しているのは、同じ発生元のポリシーのために攻撃者がスクリプトタグを含めただけではこのリクエストが失敗するためです。

なぜsynchronous AJAXを使用しているのかについては、デザインの悪さ以外に理由はないと思います。

2
Alexander O'Mara