問題は、実際に何を達成したいかということです。CSRF 攻撃と戦いたい場合は、セッション キーに加えてシークレット トークンを使用することをお勧めします。ただし、すべてのリクエストでトークンを変更すると問題が発生します-戻るボタンでセッションが強制終了されるだけでなく、通常、1 つの Web ページには非同期および並列に読み込まれたデータ (画像、CSS、JavaScript など) が多数含まれているため、アプローチ追加のリクエストごとに必要なトークンが変更され、セッションが強制終了されるため、後で追加のデータをロードすることはできません。
BASE64 やその他のトリックを使用してすべてのリソースをページに埋め込むことでこれを回避できますが、これは可能性を著しく妨げ、一部のブラウザーとの互換性の問題が発生する可能性があります。
したがって、最終的には、あなたのアプローチによってセキュリティが強化されることはほとんどありませんが、顧客にとって一連の潜在的な問題が発生する可能性が高くなります。URL のセッションごとに 1 つのシークレット トークンに固執して、CSRF と戦い、XSS などの他の攻撃や、スマートフォンなどを使用した 2 要素認証などのユーザー フレンドリーなセキュリティ対策に集中することに専念します。結局のところ、ユーザーは最近の攻撃ベクトルの第 1 位です。
更新 (2012-06-14)
トークンは XSS 攻撃には対抗しませんが、基本的な CSRF 攻撃に対して防御します (たとえば、画像に偽の URL 呼び出しを埋め込むことによって)。私は実際に今日、ユーザーの変更に対して get-request を保護し、いくつかのコードを作成する必要がある状況に遭遇しました。formコードは、静的、セッションタイムアウト、およびトークンを保護するためにも使用できる場合がありlinkます（問題が解決しました）。
アイデアは、セキュリティで保護するデータに対してハッシュ/AuthToken を生成するために使用されるサーバー シークレットを持つことです。不正な JavaScript が指定されたデータのいずれかを変更しようとすると、AuthToken が一致しなくなります。私の特定の問題では、ユーザーを認証するサーバーが1つあり、その情報を第三者に送信する必要があります（ユーザー名、メールアドレス、名前など）。この GET-Request は、認証後にユーザーが簡単に変更できる可能性があるため、GET-Request-Parameters を認証する必要があります。AuthenticationToken-Process を再実行することで、サード パーティは結果の AuthToken を比較し、受信データを検証できます。共有秘密がなければ、データを偽造することは (ほぼ) 不可能です。
あなたの問題について: GET および POST リクエスト (または私のプロジェクトのような動的トークン) で静的トークンを使用すると、ユーザーが攻撃を受けるためにクリックする必要があるフォーラムのリンクなどを介した単純な CSRF 攻撃から保護されます。リンクに正しいトークンが含まれることはないため、Web ページは安全です。ただし、攻撃者が XSS を介して Web ページに JavaScript をロードすることに成功した場合、JavaScript はページの DOM ツリー全体をスキャンしてトークンのキャプチャを見つけることができるため、これに対して役立つ技術はありません。何でも。
したがって、これは次のようになります。
- GET および POST リクエストでトークンを使用して CSRF と戦う
- XSS インジェクションからページを保護する