CSRFトークンをリプレイから保護することは有効ですか（タイムスタンプなど）？
ASP.NET MVCの AntiForgeryToken 機能を使用しているMVCアプリがあります。これは、暗号化されたシンクロナイザートークンのバリエーションを使用してトークンのペイロードを検証します。
顧客は、これらのトークンに有効期限はなく、キャプチャされた場合、特定のユーザーのセッションに対して引き続き有効であるという事実に疑問を投げかけました。
これはis可能です customize タイムスタンプをトークンに追加して検証し、発行されたトークンを期限切れにします。
私は何を考えているのですか、これは必要ですか？ CSRFトークンはリプレイ保護を提供する必要がありますか？攻撃にはMitMまたはXSSの脆弱性が必要ではないのですか？
有効期限が長すぎることは多層防御戦略の合理的な部分であると思いますが、CSRF防止スキームのセキュリティ問題としてリプレイが発生するのは奇妙です。
何が欠けていますか？
CSRFトークンが傍受される可能性がある場合、通常はセッションCookieも傍受される可能性があるので、CSRFはそのシナリオでは当面の懸念事項ではありません。
一部のCSRFトークン実装には有効期限が設定されていますが、これは追加の予防策であり、厳密に必要なわけではありません。 この答え tylerlは、トークンが何らかの方法でリークされた場合の有効期限は適切な予防策ですが、セッションの終了時にCSRFトークンを期限切れにしても問題ないことを示唆しています。
CSRF攻撃では、攻撃者はセッションから任意のフォームデータを送信することができますが、Cookieを変更することはできません。 CSRFトークンが有効であるためには、攻撃者がその値を知ることは不可能であるべきです。攻撃者が脆弱性を悪用してCSRFトークンを取得する場合、脆弱性が修正されると、CSRFトークンが無効になるようにする必要があります。セッションが期限切れになったときにトークンCookieが期限切れである限り、すべて正常です（トークンが漏洩した疑いがある場合にセッションを強制的に期限切れにする場合）。
リンクしたドキュメントから、実際には 暗号化トークンパターン を使用しているように見えます。これは、二重送信Cookieとシンクロナイザトークンを組み合わせたものです。
私たちは長年にわたって多くのクライアントとこの議論を重ねてきました。 CSRF保護の最も有効なソリューションは、サーバーがクライアントに送信された「ページ」を追跡し、サービスが提供されたクライアントからのみ、サービスが提供されたページからの有効なデータのみを受け入れるソリューションです。
私がMSのプログラミング側にいるのは久しぶりですが、@ AntiForgeryTokenはすべてのリクエストで変更され、データを受信する各ページで検証される必要があります。
アプリケーションはトークンを1回だけ生成し、その後は決して生成しないかのように聞こえます。詳細については、このブログをご覧ください。 http://blog.stevensanderson.com/2008/09/01/prevent-cross-site-request-forgery-csrf-using-aspnet-mvcs-antiforgerytoken-helper/