CSRF に関するDoctype のエピソードを見たところです。
CSRF の最善の予防策は、ユーザー固有のデータ (セッション ID のハッシュなど) からトークンを作成し、それをリクエストと共に POST することです。
推測しにくい値 (GUID など) を生成し、それをセッション変数として保存し、非表示フィールドとしてページに配置するのは安全性が低くなりますか?
ページが読み込まれるたびに値が変更されますが、POST されたデータのテストはその前に行われます。
これは私には安全に思えます。私が間違っている？
トークンがどこから来るのかは、推測や決定が不可能である限り、おそらくそれほど興味深いものではありません。ただし、リクエストごとに新しいトークンを生成することに注意してください。これは、サイトに対して 2 つ以上のブラウザー タブを開くユーザーに対してサイトが機能しないことを意味するためです。ユーザーのセッション中に 1 つのトークン値に固執することで、この問題を回避できます。
リクエストごとにトークンを変更すると、間違いなくより安全になります。しかし、ペナルティは高すぎると考えられます。セキュリティに関しては、ほとんどすべての場合と同様に、ユーザー エクスペリエンスの使いやすさとトレードオフを取らなければならないことがよくあります。CAPTCHA を楽しんでいるユーザーを 1 人見つけてください! アプリケーションとユーザーにとって適切なバランスを見つけることは、セキュリティと使いやすさの両方にとって重要です。
Open Web Application Security Projectには、CSRF (およびその他の多く) に関する良い読み物があります。
また、トークンで保護されたページにクロスサイト スクリプティングの脆弱性が 1 つでもある場合、CSRF トークンは役に立たなくなることにも注意してください。OWASP XSS (クロス サイト スクリプティング) 防止チート シートも参照してください。