フォームでCSRFトークンを使用しているとしましょう。しかし、サイトに見過ごされているXSSホールがあることがあります。
私が理解していることから、この場合、攻撃者はXSSを介してXMLHttpRequestを使用してCSRFトークン保護を取得できるため、CSRFトークン保護は完全に無効になります。
そのような場合、攻撃に耐えられるようにCSRF保護を強化する方法はありますか、それとも、CSRFの王様を行う前に、まずサイトに安全なアンチXSS保護を設定する必要がありますか？
ログイン時のトークンではなく、ページリクエストごとに新しいトークンを設定すると、それを処理できますか？これは、一度により多くのフォームを開くという問題を引き起こし、私はそれが好きではありません。
あなたのサイトはあなたが見つけたXSSの穴をすべて閉じているはずです。さもなければCSRFは役に立たないです。ただし、CSRFを並行して追加すると、すべてのXSSバグが修正されると、サイトのcsrf保護も機能するようになります。
残念ながら、XSSホールがある場合、攻撃者がWebサイトを読み取ってトークンをチェックする可能性があるため（javascriptを使用）、CSRFから保護する方法はありません。したがって、トークンを追加する方法や場所を問わず、そのトークンを見つけてスクリーンスクレイピングすることができます
ただし、重要なページにXSSバグがないことを確認してから、CSRF保護を追加すると、セキュリティホールは残りますが、複数のバグを連鎖させるために必要なスキルレベルはより困難になります。
簡単な回答： XSSの脆弱性がある場合でも、その基盤を維持するOrigin header check唯一のcsrf保護メカニズムです。
これらは、CSRFを防ぐために使用する手法です。
Synchronizer Tokenアプローチでは、サーバーは動的な非表示変数を入力フォームに埋め込み（細心の注意を払ってください。サーバーは、ランダムな文字列を生成してフォームに埋め込むことができるように、フォームの生成を完全に制御する必要があります）、サーバー側のセッション->フォーム送信で確認し、一度使用するとすぐにセッションから無効にします。マイクロサービスはSPAのフォーム生成メカニズムにアクセスできないため、これは完全に分離されたSPA（シングルページアプリケーション）に電力を供給するRestfulサービスでは機能しません。フォームが送信されると、サーバーは非表示の変数が存在し、それが正しい値であることを確認できます。ほら、これは本文で送信されています（この新しいトークンをフォーム本文ではなくCookieに設定すると、すべてが無効になります。
mybank.comがフォーム入力をサニタイズしていない場合（つまり、mybank.comがxssに対して脆弱である場合）、ハッカーはこのcsrf防止方法を克服できます。https://rileykidd.com/2013/09/09/using-xss-to-csrf/
二重送信Cookieアプローチでは、2つのCookieがブラウザに返送されます。1つはセッションIDで、もう1つはランダムな値です（シンクロナイザートークンと同様）。たとえばsessionid、csrfidこれらのCookieです。
このメカニズムを機能させるには2つのことがあります。
1）ブラウザに組み込まれている。と呼ばれる機能Same Origin Policy。これにより、スクリプトコードが他のサーバーエンドポイントと対話できるのは、それらのエンドポイントが、そのスクリプトコードを配信したエンドポイントと同じオリジン（ベースURI）を持っている場合のみです。不思議に思うかもしれません。1つのCookieがそれ自体で安全でない場合、2つのCookieはどのようにしてより安全になりますか？」ちょっと待ってください、鍵は次のポイントにあります
2）2番目のCookie（csrfid）をカスタムヘッダーの後続のリクエストに含める（たとえば、X-XSRF-Token）。これが正しく設定されていることを確認するのは、クライアントのスクリプトコード次第です。
ログインページをリクエストすると、サーバーから2つのCookieが返送されます。2番目のCookieは、ブラウザからの後続のリクエストのカスタムヘッダーで使用されます。サーバーはカスタムヘッダーの存在をチェックし、そのページに送信されたものに対して値をチェックします。
Synchronizer Tokenのアプローチと同様に、ページをスプーフィングしてアクティブなセッションにデータを送信するように仕向けようとする外部サイトは、サイトのカスタムヘッダーを別のURLに設定できないため、失敗します。
サーバーは、ランダムな値のcsrftoken cookieを生成し、セッションが確立されたときにそれをブラウザーに送信する必要があります。
クライアントはCookieにアクセスし、後続のすべてのリクエストに対してカスタムヘッダーに設定する必要があります
サーバーはCUSTOMHEADERを確認する必要がありますcsrfid（Cookie（または指定した名前）を無視します。Cookieなので、とにかくすべてのリクエストで存在します。無視してください）
すべてのブラウザが同一生成元ポリシーを実装しているため、この手法は効果的です。Cookieが設定されているWebサイトのコードのみが、そのサイトからCookieを読み取り、そのサイトへの要求にカスタムヘッダーを設定できます。
未解決の質問（これをテストする機会はまだありませんでした）：httpOnly2番目の（csrf-token）Cookieはどうですか..設定する必要がありますか？..設定すると、Javascriptはそれにアクセスして、後続の各リクエストに設定できるようになります。一方、Javascriptがアクセスできる場合は、sanitized-form-negligence XSSの脆弱性とともに、XSS攻撃によってユーザーのcsrfトークンが公開される可能性があります。次に、mybank.comでアクティブなセッションを行っているときに、evil-guyがユーザーをだましてevil-site-which-has-a-csrf-form.comにアクセスさせることができれば、csrf攻撃が発生する可能性があります。同意しました。攻撃を行うには「 if 」が多すぎますが、それでも安全ではありません。
XSSの脆弱性がある場合、これらの方法ははるかに効果的ではありません。3番目のオプションを見てみましょう
Internet Explorer 9以降を含むすべてのブラウザーはOrigin、要求でヘッダーを送信します。このヘッダーをJavascriptで設定することは許可されていません。これにより、ブラウザーがそのヘッダーに正しい情報を持っているという高い信頼性が得られます。次に、サーバーはそのヘッダーを明示的にチェックし、ベースURIがサーバーのURIと一致することを確認できます。OriginヘッダーのベースURIが期待値と一致しないブラウザリクエストをサーバーが拒否するように設定されている場合、ブラウザに設定されたOriginが次のようになるため、ページの外観をスプーフィングしようとするサードパーティサイトは失敗します。予想とは異なります。
mybank.comにXSSの脆弱性がある場合でも、これは失敗しません。灘を捕まえろ！ユーザーが（非常に）古いバージョンのブラウザを使用している場合は、とにかく解決すべき他の問題がある可能性があります:)
参照： https ：//stormpath.com/blog/secure-single-page-app-problem