在Azure中出现“防伪cookie令牌和表单字段令牌不匹配”的随机问题

4
我们的网站托管在Azure上,日志中出现了随机的“防伪Cookie令牌和表单字段令牌不匹配”的错误。我们意识到需要一个静态的机器密钥,于是在web.config中添加了validationKey和decryptionKey属性,但是我们仍然会遇到随机的错误弹窗。
这里所说的“随机”,指的是每200-300个表单提交中会出现一两次。这种情况发生太频繁了,对于信任我们服务的客户来说真的很影响体验。
我想到另一个可能的原因是,这种情况是否发生在禁用了cookie的机器上。我无法验证这一点,但我不知道ValidateAntiForgeryToken是否需要cookie。如果确实需要cookie,那么我们是否应该向用户弹出消息,告诉他们需要启用cookie以便正常使用?
我需要帮助找出故障的方法或其他处理方式的想法。
谢谢您的帮助。
[更新] 我刚刚从一个出现此错误的用户那里得到了消息。结果发现他们加载页面后离开了一段时间,导致了这个错误。这是个好消息,因为这意味着验证正在起作用,没有发生什么奇怪的事情......我只需要验证这个数据点是否代表其他用户。那么,在令牌过期的情况下,您们如何以清晰的方式通知用户?

有人试图提交恶意表单数据吗?也就是说,令牌是否发挥了作用? - Liam
真的,谁知道呢。没有重现步骤,可能有很多原因。 - Liam
这些都是真实用户,他们正在尝试合法地使用我们的服务,所以我不认为他们会提交恶意表单数据。还有其他形式的恶意数据,比如使用HTML或脚本标签,但那会生成不同类型的错误。 - lostdeveloper
至于复制步骤,这是所有问题中最困难的部分,因为我们无法自己复制它。整个情况都很奇怪。 - lostdeveloper
也许这会有所帮助:https://dev59.com/5W025IYBdhLWcg3w1ZkL - Peter B
显示剩余2条评论
2个回答

0

您是否拥有服务器群?例如启用了自动缩放的应用服务或具有多个机器的云服务?

如果是,请检查所有 web.config 文件中是否定义了相同值的 machinekey。machinekey 用于生成防伪标记。


我假设我们在Azure中,自动处于某种服务器农场中。 machineKey 在已部署的单个 web.config 中定义,因此我看不到有冲突的 web.config 文件的机会。 - lostdeveloper
ASP.NET默认使用的Cookie来管理AntiForgery令牌是**__RequestVerificationToken**。 - Toine Seiter
如果您拥有Azure应用服务,可以前往portal.azure.com > 应用服务 > 您的应用 > 应用服务计划 > 扩展来检查您的自动缩放策略并查看您有多少个实例。 - Toine Seiter
我查看了实例计数。它被配置为“手动输入的实例计数”。目前设置为1。 - lostdeveloper
好的,所以你只有一个带有定义机器密钥的服务器。你尝试双击提交引发错误的页面了吗? - Toine Seiter
好的建议。我尝试了多次点击,但仍然无法使其中断。 - lostdeveloper

0

你能记录失败请求的头信息吗?你可以在 global.asax 的 Application_Error 中添加一些代码,例如:

foreach (string header in request.Headers)
{
     // header <== header name
     // request.Headers[header]) <== header value
 }

首先,再次感谢您的帮助。非常感激。至于记录标题,我应该在其中寻找什么?此外,我正在根据我刚收到的用户反馈更新这个问题。 - lostdeveloper
您将能够查看是否存在防伪标记令牌 cookie,以及可能的其他有趣信息。在应该具有此 cookie 的 URL 上没有此 cookie 的 POST 请求可能是爬虫或黑客的攻击。 - Toine Seiter
1
如果所有的标头都正常,那么问题可能出在用户的使用上。让我们考虑以下使用情况: 1)您的表单位于缓存页面上(客户端缓存)。生成一个防伪令牌A。2)用户验证表单3)然后点击浏览器的返回按钮4)用户重新验证表单(使用旧的A令牌)5)asp.net等待反伪造令牌B并获取A。所以它会抛出异常。为了避免这种情况,在包含反伪造的表单的URL上应禁用客户端缓存。 - Toine Seiter

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接