CSRFセキュリティのトークン更新はどのくらいの頻度で行う必要がありますか？

背景から始めるために、この投稿はCSRFトークンについてJeff Atwoodが述べたものです。このページで、彼は続けて言っています：

さらに強力ですが、より複雑な防止方法は、サーバーの状態を活用することです。つまり、クライアントに送信するすべてのHTMLフォームに対して一意のランダムキーを生成（およびタイムアウト付きで追跡）します。Stack Overflowでこのメソッドのバリアントを使用して、大きな成功を収めています。

しかし、この投稿自体では、Jeffはトークンをいつ、どのように更新する必要があるかについて決してコメントしていません。

私が取り組んでいるWebアプリで同様のテクニックを使用していました。それはこのように動作します：

1. ユーザーがPOSTサーバーにデータを送信するたびに、csrfトークンが送信されます。
2. このCSRFトークンは、ユーザーのセッションで暗号的に強力なCookieに保存されます。
3. トークンが有効な場合は、ユーザーのリクエストが処理され、逆の場合も同様です。
4. リクエストが有効な場合は、サーバー側の古いトークンを破棄し、新しいトークンを作成します。サーバーからの応答には、次の要求で使用される新しいcsrfトークンが含まれています。ページ上のすべてのフォームの古いトークンが新しいトークンで更新されるため、次のリクエストが適切に処理されます。

トークンを更新してからPOSTリクエストするのが賢明ですか、それともユーザーがGETリクエストを行ったときにのみ更新を行い、次のGETリクエストが行われるまで同じトークンを保持する必要がありますか？

CSRFトークンの主なポイントは、別のサイトから送信できないことです。したがって、（a）攻撃者が予測または検出することはできず、（b）Cookieのようにリクエストに自動的に添付されることはありません。

したがって、理論的には、CSRFトークンが第三者に開示されない場合、理論的には、それらを期限切れにする必要はまったくありません。ただし、トークンが何らかの形で「漏洩」するリスクがあります。したがって、有効期限は、トークンが取得されてユーザーに対して使用される可能性に対抗するのに十分なほど短いはずです。

実際にはガイドラインはありませんが、署名付きのタイムコードを埋め込むすべてのリクエストで新しいトークンを自動生成し、特定の年齢までのトークンを受け入れることをお勧めします。

関数の例は次のとおりです。

concat(current_time,salt,sha256_sum(concat(salt,userid,current_time,secret_string)))

トークンにはタイミング情報とソルトが含まれていますが、偽造できず、ユーザーIDに関連付けられている署名も含まれています。

次に、独自の有効期限を定義できます-1時間、1日、2時間。なんでも。この場合の間隔はトークンに関連付けられていないため、有効期限ルールは自由に設定できます。

ただし、少なくとも、CSRFトークンは、ログインセッションが期限切れになったとき、またはユーザーがログアウトしたときに期限切れになるはずです。ログアウトする前に表示したフォームが、再度ログインした後も引き続き機能することは、ユーザーが期待することではありません。