保护CSRF令牌不被重播(例如带有时间戳)有效吗？

Question

我有一个MVC应用程序，它使用了AntiForgeryToken的ASP.NET MVC功能。AFAICT --它使用加密的同步器令牌变体来验证令牌的有效负载。

一个客户质疑这些令牌不会过期的事实，如果捕获了，那么对于给定用户的会话仍然是有效的。

自定义可以向令牌添加时间戳并对其进行验证，从而使发出的令牌在一个时间段后过期。

我想知道的是，这有必要吗？CSRF令牌应该提供重放保护吗？攻击不需要MitM或XSS漏洞吗？

我某种程度上认为，长期失效是防御深度战略的一个合理部分，但我觉得奇怪的是，重播会被作为一个安全问题提出一个CSRF预防计划。

我遗漏了什么？

Answer 1

如果CSRF令牌可以被截获，那么会话cookie通常也可以被截获，所以CSRF不会是该场景中的直接关注点。

有些CSRF令牌实现有计时到期，但这是额外的预防措施，并不是绝对必要的。来自tylerl的这个答案建议，如果令牌被泄露，过期是一个很好的预防措施，但是在会话结束时终止CSRF令牌是可行的。

在CSRF攻击中，攻击者可以从您的会话中提交他们想要的任何形式的数据，但是他们不能修改您的cookie。要使CSRF令牌有效，攻击者不可能知道它的值。如果攻击者利用漏洞获取CSRF令牌，则希望确保一旦漏洞修复，CSRF令牌就不再有效。只要令牌cookie在会话到期时过期，一切都是安全的(如果您怀疑令牌已被泄露，则强制会话过期)。

从您链接的文档来看，在我看来，它实际上使用的是加密令牌模式，它将双提交Cookie与同步器令牌结合在一起。

Answer 2

这些年来，我们与许多客户进行了这种讨论。CSRF保护最有效的解决方案是，服务器跟踪向客户端发送了什么“页面”，然后只接受来自所服务页面的有效数据，只接受它所服务的客户端的有效数据。

我已经有一段时间没有使用MS进行编程了，但是@AntiForgeryToken应该随每个请求而改变，并在每个接收数据的页面上进行验证。

听起来，应用程序只生成一次令牌，然后就不再生成了。查看这个博客，了解更多的细节。http://blog.stevensanderson.com/2008/09/01/prevent-cross-site-request-forgery-csrf-using-aspnet-mvcs-antiforgerytoken-helper/

Answer 3

“抗重播”身份验证阻止MITM存储通信量并能够代表受害者执行请求。

CSRF是一种攻击，允许入侵者使用有效的会话(无论是否存储)来代表受害者执行请求。

CSRF令牌确保仅访问会话并不授予代表受害者执行请求的访问权限。因此，它还可以防止“抗重播”身份验证，因为攻击者不仅必须拥有经典的HTTP存储会话，而且如果实现得好，还需要更难获得CSRF令牌。

因此，问题的答案是“不，保护CSRF令牌不被重播是无效的，因为CSRF令牌实际上是能够防止重放的令牌。如果CSRF令牌实现需要”防御“重播，那么实现就不够好。”

为了深入研究CSRF令牌的良好实现，下面是要做的事情(请注意，CSRF令牌保护不仅仅是在接收请求时要求令牌，还包括何时将该令牌发送到前端，以及前端如何保存该令牌)：

1. 不支持旧浏览器。例如，这可以确保默认情况下为cookies设置SameSite=lax，并提供大量可以从服务器端发送的头部，以使浏览器减少前端相关的攻击。另一个说明为什么使用最新浏览器版本很重要的例子是新浏览器使用的默认“相同来源策略”，以及它们对通过内容-安全-策略头进行控制放松的支持。底线，再次，停止旧浏览器使用你的应用程序。冒着每个人的风险，因为很少有人不升级他们的浏览器是完全不正确的方法。
2. 不提供CSRF令牌，不允许任何后端持久化。因此，例如，如果您的API实现没有遵循纯粹的REST方法，那么考虑检查CSRF服务器接收到的所有内容，包括是的，GET请求。
3. 成功登录后，只将令牌作为HTTP标头返回一次。
4. 将CSRF令牌存储在本地浏览器存储区中，绝不作为cookie存储。这是至关重要的，因为如果您使用cookie，那么您的浏览器将发送CSRF令牌，而不管您代表哪个站点。只有当用户从应用程序域运行前端代码时，才能访问CSRF令牌。
5. 如果收到不正确的CSRF令牌，则禁用会话。