リクエストヘッダーに存在しない場合、CSRFトークンをフロントエンドに提供する
ユーザーがページをリクエストするとCSRFトークンが生成され、非表示のjspフィールドのinputページに挿入されるWebアプリがあります。
次に、同じヘッダーがカスタムヘッダーのAJAX呼び出しごとにサーバーに送信されますが、セッション状態トークンはCookie（secure + httpOnly）。
これで、CSRFトークンはWebアプリケーションで新しいものであるため、更新後にユーザーがすでにログインしていて、ユーザーがリクエストを送信した場合、Filterは実際にログインしていると判断します（ Cookieのセッション状態トークンが原因で）、有効なCSRFトークンがカスタムヘッダーに含まれていないため、定義された動作はログアウトすることです。
[〜＃〜] owasp [〜＃〜] の例に従うことで、これに対処できます。 CSRFトークンが存在しない場合は、NO-CONTENTリクエストを送信して、トークンを提供するつもりです。
これが最初の疑問です：
さらに、リクエストに欠落している場合、CSRFトークンを返してくれます。これはanti-secureのようです：攻撃者がcookieからセッショントークンを盗んだ可能性があります。リクエストを送信し、魔法のようにCSRFトークンを受け取ります。
したがって、ここでは混乱します。
CSRFトークンをセッションステートトークンと一緒にCookieに入れるだけですか？CSRFトークンが何も設定されていないが、セッション状態のCookieが存在する場合、トークンの提供を避けるべきですか？- 私のケースの代替ソリューションは何ですか？
注：
CSRFトークンを確認する前に、アドバイスに従ってOriginおよびrefererヘッダーを確認します here 。
use-only-one-per-request CSRFトークンを実装する予定はありません。
このコンテキストには関係ありませんが、通信はHTTPS経由で行われます
CSRFの脆弱性に対処する方法は複数あります。あなたが見ている実装は、CSRFトークンを管理するステートレスな方法を使用しています。これは、二重送信Cookieメソッドと呼ばれます。これにより、サーバー側でCSRFトークンを追跡したくない場合の労力を節約できます。
質問で共有した [〜＃〜] owasp [〜＃〜] リンクから：
二重送信Cookieは、Cookieとリクエストパラメータの両方でランダムな値を送信するものとして定義され、サーバーはCookie値とリクエスト値が一致するかどうかを確認します。
セキュリティリスクは、CSRFトークンがCookieにのみ存在し、他の場所には存在しない場合に発生します。これは、別のセッションCookieを持つことと同じであるため、CSRF防止には十分ではありません。
二重に送信されたCookieの実装では、Cookieとフォームパラメータから受け取ったトークン値が同じであることを確認する必要があります。 CSRF攻撃の場合、偽造されたリクエストにはCookieにトークンが含まれますが、fromパラメータ/カスタムヘッダーのトークン値は存在しません。したがって、CSRFの検出と防止につながります。
リクエストが認証されているが、まだトークンが含まれていない場合にCSRFトークンを返すことについての他の質問に答えるためこれは、ユーザーに求めるユーザーエクスペリエンスの種類に完全に依存します。場合によっては、ユーザーをログインページにリダイレクトしてもかまいません。
Cookieでトークンを返し、CSRFの試みがあったとします。このような場合、 Same Origin Policy を使用すると、悪意のあるドメインがCookieの値に直接アクセスできないため、上記と同じ理由で後続の偽造リクエストが失敗します。
二重に送信されたCookieの実装の場合のセキュリティに関する追加の考慮事項：