提问人：LFN 提问时间：11/17/2023 最后编辑：LFN 更新时间：11/17/2023 访问量：24
“新标签页”和“自动打开标签页（点击外部链接时）”之间的浏览器功能不一致 - 导致 Invald asp.net 核心 VerificationTokens
Inconsistent browser functionality between "new tab" and "auto open tab (on external link click)" - causes Invald asp.net core VerificationTokens
问：
以下奇怪的行为在 Firefox 119 和 Chrome 119 之间是一致的。
在 asp.net 核心应用程序的上下文中，我希望了解在浏览器中打开“新标签”与浏览器自动打开以提供外部点击链接之间的区别。对生成的 asp.net 核心 RequestVerificationToken 的影响是不一样的。
手动打开新的浏览器选项卡（并粘贴链接）时，asp.net 核心 VerificationToken 有效。当浏览器选项卡自动打开时（从外部点击的链接 - 从电子邮件等提供页面），它不是。 相同的链接。同一页。相同的形式。当无效的 VerificationToken 被 POST 时，POST 将命中 404 或 401 或应用程序设置为执行的任何操作。
每当浏览器中已经存在来自同一域的选项卡时，这似乎是正确的，所以我怀疑这与选项卡等之间的 cookie 泄漏有关 - 但是为什么只有当选项卡自动打开以加载 URL 时，而不是手动打开一个并粘贴链接？我希望有一致的行为。
我唯一能掌握的是，自动打开的选项卡似乎会导致生成的验证令牌更短。为什么只有一种情况会如此？缺少什么（或额外）？
我将 [IgnoreAntiforgeryToken] 属性添加到接收 POST 处理程序中，问题就消失了。这确实是选项卡打开方式的结果。但是它们如何打开的结果是什么？
答：
1赞
Jalpa Panchal
11/17/2023
#1
手动打开的选项卡和自动打开的选项卡所面临的问题可能是因为浏览器安全性、会话处理以及 Web 应用程序管理状态和身份验证令牌的方式。RequestVerificationToken
现代 Web 浏览器实施同源策略，以限制从一个源加载的文档或脚本如何与另一个源的资源进行交互。此政策还会影响 Cookie 处理。当您在新标签页中手动打开链接时，浏览器会将其视为现有会话的延续。但是，当链接像电子邮件一样自动打开时，浏览器可能会将其视为可能不太受信任的操作，并应用更严格的安全措施，从而影响 cookie（包括会话 cookie）的处理方式。
浏览器发送 HTTP 反向链接标头的方式可能因新选项卡的打开方式而异。某些 Web 应用程序可能会使用反向链接作为其安全机制的一部分。自动打开链接可能会发送与手动打开新选项卡并粘贴 URL 不同的引荐来源。
防伪令牌的生成和验证可能会受到用户会话和浏览器安全上下文的影响。自动打开选项卡时，某些会话变量或安全上下文的传输方式可能与手动打开选项卡时不同。
关于自动打开的选项卡导致验证令牌更短的观察结果，特别令人好奇。这可能表示令牌的生成或截断方式存在差异，这可能是由于可用会话或用户上下文信息的差异所致。
您可以尝试检查浏览器控制台日志，检查网络日志，在生成和验证令牌时跟踪会话状态详细信息，以查看是否存在差异。在不同的浏览器中进行测试。
评论