ハッカーがトークンの値を知らないというCSRF保護の背後にある中心的なアイデアは何ですか？
私はCSRFの背後にある概念を完全に理解しようとしています。さらに重要なのは、CSRFから保護する方法です。
CSRFのみを使用しているため、XSSやその他の手法がないため、ハッカーはページに挿入したランダムなCSRFトークンの値を知ることができないと思いますか？
あなたの理解は正しいです。
バックグラウンド
CSRF攻撃を考える最も簡単な方法は、ブラウザに2つのタブが開いていることです。タブA：www.mybank.comとタブB：www.attacker.comです。
（@Alexがコメントで指摘しているように、複数のタブは必要ありません。重要な部分は、ブラウザのメモリにmybank.comの認証Cookieがあることです。CSRFは、以前にmybank.comを使用していた場合にも同様に発生しますログアウトせずにattacker.comにアクセスします）
クッキー
これまで、認証/セッショントークンをCookieに保存するのが一般的でした。これは純粋なHTMLページ（つまりJavaScriptなし）に便利です。www.mybank.comにリクエストを送信すると、ブラウザが関連する認証Cookieを自動的に添付します-維持するためにHTMLページの側でアクションは不要ですセッション。 CSRFはCookieベースの認証トークンへの攻撃です。タブB（www.attacker.com）がwww.mybank.comにリクエストを送信すると、ブラウザは自動的に認証Cookieを添付します。つまり、タブBはリクエストがあったかのようにリクエストを送信できますタブAにログインしました。
ソリューション
認証/セッショントークンをCookieではない場所に置く必要があります。タブBはタブAのコンテンツを表示できないことを思い出してください。auth/セッショントークンを配置できる場所はいくつもあります。
- hTMLページのどこかに（おそらく非表示のHTML要素に）、
- または、非Cookie HTTP応答ヘッダー内
- または、これがAPIの場合は、JSON本文の
token: ___フィールドなどに配置できます。
Cookieに含まれていなければ、どこでもかまいません。
完全を期すために、攻撃者がそれを推測できないように、アンチCSRFトークンは長くランダムである必要があることを付け加えます。たとえば、すべてのユーザーに同じ抗CSRFトークンを使用する場合、またはユーザー名から派生する場合、トークンを推測し、彼らのブラインドCSRFリクエストにそれを含めてください。