ASP.MVC 防伪令牌和加密错误

发布于 2024-08-09 15:07:05 字数 685 浏览 3 评论 0原文

我正在使用 ELMAH 来处理我的 MVC 站点中的错误,并且在过去的几周里我注意到我抛出了一些 CryptographicExceptions。消息是:

System.Security.Cryptography.CryptographicException:填充无效且无法删除。

System.Web.Mvc.HttpAntiForgeryException: 未提供所需的防伪令牌 提供或无效。 ---> System.Web.HttpException:验证 viewstate MAC 失败。如果这个 应用程序由 Web Farm 托管或 集群,确保 配置指定相同 验证密钥和验证 算法。无法使用自动生成 在一个集群中。 --->

该应用程序没有在集群中运行,我似乎无法重现这些错误。它们看起来像是有效的请求——而不是手工制作的帖子——并且确实包含 __RequestVerificationToken cookie。我在页面上的表单(我的登录表单)内确实有所需的 HTML 帮助程序。

我还没有收到任何用户投诉,所以我假设它最终适用于尝试登录的人,但我想知道为什么会发生这种情况。

其他任何看到这种行为或对如何诊断异常有任何想法的人——就像我说的,我不能让它失败。删除 FF 中的 cookie 会出现不同的错误。修改 cookie(更改或删除内容)也会导致不同的错误,就像修改页面上隐藏令牌输入的内容一样。

I'm using ELMAH to handle errors in my MVC sites and I've noticed over the past couple of weeks that I'm getting some CryptographicExceptions thrown. The message is:

System.Security.Cryptography.CryptographicException: Padding is invalid and cannot be removed.

System.Web.Mvc.HttpAntiForgeryException:
A required anti-forgery token was not
supplied or was invalid. --->
System.Web.HttpException: Validation
of viewstate MAC failed. If this
application is hosted by a Web Farm or
cluster, ensure that
configuration specifies the same
validationKey and validation
algorithm. AutoGenerate cannot be used
in a cluster. --->

The application is not running in a cluster and I can't seem to reproduce these errors. They look like valid requests -- not a hand-crafted post -- and do contain the __RequestVerificationToken cookie. I do have the required HTML helper on the page, inside the form (my login form).

I haven't had any user complaints, yet, so I'm assuming that eventually it works for whoever is trying to login, but I'm left wondering why this could be happening.

Anyone else seeing this behavior or have any ideas on how to diagnose the exception -- like I said, I can't get it to fail. Deleting the cookie in FF comes up with a different error. Modifying the cookie (changing or removing the contents) also results in a different error, as does modifying the contents of the hidden token input on the page.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

浅沫记忆 2024-08-16 15:07:05

我不确定是否存在相关性,但在添加排除我的登录操作的 robots.txt 文件后,我不再看到这些错误。我怀疑这与爬虫点击页面并尝试调用登录操作有关。

编辑:在应用程序池回收后接收旧cookie时,我也看到了这个问题。我已采取显式设置 machineKey 的方式,以便应用程序重新启动时对验证/解密密钥的更改不会影响可能重新发送的旧 cookie。

更新站点并转到固定的 machineKey 后,我发现我仍然从拥有先前版本的 cookie 的人那里收到这些错误。作为临时解决方案,我添加了以下 Application_Error 处理程序:

    public void Application_Error()
    {
        var exception = Server.GetLastError().GetBaseException();
        if (exception is System.Security.Cryptography.CryptographicException)
        {
            Server.ClearError();
            if (Request.IsAuthenticated)
            {
                var form = new FormsAuthenticationWrapper();
                form.SignOut();
                Session.Clear();
            }
            Response.Cookies.Clear();
            Response.Redirect( "~" );
        }
    }

I'm not sure if there is a correlation, but after adding a robots.txt file that excludes my login actions, I am no longer seeing these errors. I suspect that it has to do with a crawler hitting the page and trying to invoke the login action.

EDIT: I've also see this issue when receiving old cookies after the application pool has recycled. I've resorted to setting the machineKey explicitly so that changes to the validation/decryption keys on application restarts don't affect old cookies that may be resent.

After updating the site and going to a fixed machineKey I found that I was still getting these errors from people who had cookies from the previous version. As a temporary work around I've added the following Application_Error handler:

    public void Application_Error()
    {
        var exception = Server.GetLastError().GetBaseException();
        if (exception is System.Security.Cryptography.CryptographicException)
        {
            Server.ClearError();
            if (Request.IsAuthenticated)
            {
                var form = new FormsAuthenticationWrapper();
                form.SignOut();
                Session.Clear();
            }
            Response.Cookies.Clear();
            Response.Redirect( "~" );
        }
    }
纸伞微斜 2024-08-16 15:07:05

我不太确定这与防伪系统有什么具体关系,内部异常状态为“视图状态 MAC 验证失败。”,据我所知,防伪系统的默认基础设施依赖于视图状态(实际上,如果您看看这里,您就会请参阅依赖性和恐怖(底部的 CreateFormatterGenerator 方法))。

至于为什么 viewstate mac 在假请求上失败,我不确定 - 但考虑到反序列化防伪令牌(处理整个假请求)中存在的恐怖,它一点也不让我感到惊讶。

I'm not so sure this has anything specifically to do with the antiforgery system, the inner exception states 'Validation of viewstate MAC failed.', from what I can tell, the default infrastructure for the antiforgery system has a dependency on the viewstate (actually if you take a look here you'll see see the dependency and horror (the CreateFormatterGenerator method at the bottom)).

As for why the viewstate mac is failing on the fake request, I'm not sure- but given the horror that exists in deserializing the antiforgery token (processing an entire fake request), it doesn't suprise me at all..

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文