CSRF攻撃を緩和するために2つのCSRFトークン（非表示フィールドとCookie）が必要なのはなぜですか？
私は、Webセキュリティに関するPluralsightコースを見てきました。CSRF攻撃を緩和するには、Webサイトは2つの「ペアの」CSRFトークンをクライアントに返す必要があります。ユーザーのセッション。これらのトークンは、ユーザーがフォームなどのページにアクセスするたびに発行されます。
現在、攻撃者のWebサイトは非表示のフォームフィールドトークン（同じオリジンポリシー）を取得できないため、フォームを含むページに有効なリクエストを発行できません。
しかし、CSRFを防ぐために2つのCSRFトークンが必要なのはなぜですか？フォームフィールドトークンだけでは不十分ですか？
あなたが説明しているパターンは「ダブルサブミットクッキー」と呼ばれ、CSRFを防ぐための一般的な方法です。ここでのポイントは、サーバーがトークンを覚えておく必要がないことです。クライアントはCookieと他の方法の両方でトークンを送信します。フォームフィールド。サーバーは、両方のトークンが同一であることを確認します。
これは、攻撃者がCookieを読み書きできないため、フォームフィールドでCookieを再現できないために機能します。そのため、2回送信する必要があります。
- Cookieしかない場合は、リクエストごとに自動的に送信され、保護はまったく行われません。
- フォームフィールドのみが存在する場合、比較するものは何もなく、攻撃者は任意の値を入力することができます。
1つのトークンのみを使用する、CSRFに対する他の防御策があります。最も一般的なのは、サーバーのセッション変数に正しい値を格納し、フォームフィールドがそれと一致することを確認することです。クッキーは必要ありません。ただし、これにはサーバーがユーザーごとの状態を維持する必要があるという欠点があります。
非表示のフォームフィールドであり、リクエストごとに1つのトークンで十分です（つまり、次のリクエストで送信されるすべての応答でトークンを受け取ります）。 Cookieは自動的に送信されるため、トークンをCookieに保存しないでください。
さまざまな方法があります（フレームワーク固有のものもあります）。 2つのトークンプロセスは、CSRF問題を解決するための良い方法としても機能します。 Cookie内およびページ上のトークンは、暗号的にリンクされています。したがって、サーバーはこのチェックを実行し、すべてが問題なければこの要求の処理を続行する必要があります。
CSRF攻撃を防ぐには、CSRFトークンを予想されるトークンと照合する必要があります。
Webサイトはその期待されるトークンを保存する必要があり、そのための一般的な方法はCookieを設定することです。
両方のトークンが一致する場合、フォームは有効です。