Struts2トークンインターセプターは、CSRFから保護するための実行可能な方法ですか？
私は現在、CSRFに対する対策として、すべてのフォームにデフォルトのStruts2トークンインターセプターを実装しています（ユーザーが別のWebサイトにアクセスして悪意のあるJavaScriptをトリガーすることにより、知らないうちに製品に対してアクションを実行させています）。
トークンに関するいくつかの技術仕様：使用すると、フォームに2つの非表示フィールドが作成されます。トークンの名前を含むstruts.token.nameというフィールドと、トークンの名前とランダムに生成されたトークンのフィールドです。このトークンはセッションにも保存され、トークンの名前は設定ページに記載されています。各ページトークンは、ページの名前とトークンのID（使用可能な場合）に基づいて一意の名前を持つように構成します。これにより、ユーザーは同じタイプの2つの編集ページを開いて、特定の属性をオブジェクト間でコピーすることができます。
ページが送信されると、構成ページで指定された名前のトークンがページに含まれているかどうかのチェックが行われます。そうでない場合、ページはエラーをスローします。トークンが存在する場合は、トークンがセッションに格納されているものと同じであるかどうかがチェックされます。そうでない場合、ページはエラーをスローします。両方のチェックに合格した場合、ページは通常どおり続行されます。
私の主な懸念は、悪意のあるページがJavaScriptを使用して元のページを取得し、それを独自のページに追加し、関連するトークンフィールドを取得して独自のリクエストに追加することです。それは正当な懸念事項ですか？
アプリケーションでCORS（Cross Origin Resource Sharing）が有効になっている場合、はい、攻撃者ページで実行されているJavaScriptコードがアプリケーションを呼び出し、トークンを取得して次のリクエストで送信し、クロスサイトリクエストフォージェリ（CSRF）を引き起こす可能性があります。
ただし、アプリケーションでCORSが無効になっている場合、攻撃者がページにアクセスしてトークンを取得する方法はほとんどありません。 CSRF攻撃は通常、認証されたユーザーの助けを借りて、悪意のあるコードを実行しているリンクをクリックするように仕向けることで行われます。
Strutsトークンインターセプターはトークンを1回検証してから、Sessionオブジェクトのトークンをリセットします。これにより、CSRF攻撃またはユーザーが同じリクエストを再度送信しようとしたために、他のユーザーが同じトークンを使用できなくなります（Multiple Form Sumission）。