JavaScriptを使用してクライアント側からHTTPヘッダーを操作することによるCSRF
WebサイトのCSRF脆弱性分析を実行しようとしています。私のWebサイトでは、セッションCookieを使用してサーバーからクライアントに送信されるアンチCSRFトークンを使用しています。次に、クライアントのJavascriptがそれをCookieから取得し、別のXSRF-TOKENヘッダーとして添付してサーバーに送り返します。 。
リクエストをインターセプトした後にCSRFPoCを生成し、それをhtmlファイルに保存し、別のタブでアクティブなセッションを使用して新しいタブでそのファイルを開くことにより、BurpSuiteから自分のWebサイトのXSS脆弱なフォームに対してCSRF攻撃を試みました。ブラウザはXSRFトークンを自動的に送信できませんが、すべてのCookieとその他のヘッダーに対しては送信できます。
スクリプトを使用してクライアント側から新しいXSRF-TOKENヘッダーを作成したり、既存のXSRF-TOKENヘッダーを操作したりして、リクエストとともに送信できるかどうかを知りたいです。または、XSRF-TOKENヘッダーを強制的に送信する他の方法、またはCSRF攻撃を実行する他の方法がありますか？今のところ、私が知っている唯一の脆弱性は、他のドメインからiframeで自分のWebサイトを開くことができるということです。
同一生成元ポリシー のため、別のドメインのJavaScriptは、IFrame内であっても、ドメインのコンテンツを操作または読み取ることができません。したがって、これは脆弱性ではないため、説明する攻撃シナリオはリスクではありません。
Double SubmitCookiesには他にも脆弱性があることに注意してください。 この回答 を参照してください。
CSRF保護を回避する方法は、攻撃者が代わりに クリックジャッキング を使用することです。これを防ぐには、 X-FRAME-OPTIONS ヘッダーとコンテンツセキュリティポリシーの frame ancestors ディレクティブを使用してサイトをフレーム化できないようにしてください。
最後の文はCSRFに関するものではなく、クリックジャッキングに関するものです。これらは関連していません。
XSRF-TOKENヘッダーを攻撃者として変更するために私が考えることができるのは、HTTPパラメーター汚染に対して脆弱な場合だけです。
アンチCSRFの実装をよりよく理解するには、Cookieとヘッダーがどのようにチェックされるかを説明するとよいでしょう。
Cookieの値がヘッダーの値と等しいかどうかだけをチェックする実装を見てきましたが、サーバーは2つを比較するだけでなく、その値をチェックする必要があるため、私の意見では正しくありません。