.NET 应用程序中不稳定的无效 Viewstate 问题

Posted 2023-03-31

【中文标题】.NET 应用程序中不稳定的无效 Viewstate 问题

【英文标题】：Erratic Invalid Viewstate issue in a .NET application

【发布时间】：2010-10-18 05:30:24

【问题描述】：

我的ASP.NET 应用程序的事件查看器中似乎不时出现“无效的视图状态”。

他们中的大多数 (95%) 似乎在引用 ScriptResource.axd（应用程序 使用ASP.NET AJAX 库）。我无法删除 Ajax 库，因为 Ajax 无处不在。

如何减少这些错误？我每天会遇到约 100-200 个错误，我不知道如何解决它们！它们来自不同的浏览器、不同的 IP 和地理位置。

我很难重现这个问题，因为它几乎没有发生在我身上，它只是突然发生在我身上 3-4 次。

错误：

Process information: 
    Process ID: 4004 
    Process name: w3wp.exe 
    Account name: NT AUTHORITY\NETWORK SERVICE 

Exception information: 
    Exception type: HttpException 
    Exception message: Invalid viewstate. 

Request information: 
    Request URL: http://domainnamehere/ScriptResource.axd?d=W1R6x9VzZ2C9SKnIkOmX9VRLhSjJ3nOF1GSQvPwKS3html 
    Request path: /ScriptResource.axd 
    User host address: 124.177.170.75 
    User:  
    Is authenticated: False 
    Authentication Type:  
    Thread account name: NT AUTHORITY\NETWORK SERVICE 

Thread information: 
    Thread ID: 1 
    Thread account name: NT AUTHORITY\NETWORK SERVICE 
    Is impersonating: False 
    Stack trace:    at System.Web.UI.Page.DecryptStringWithIV(String s, IVType ivType)
   at System.Web.UI.Page.DecryptString(String s)
   at System.Web.Handlers.ScriptResourceHandler.DecryptParameter(NameValueCollection queryString)
   at System.Web.Handlers.ScriptResourceHandler.ProcessRequestInternal(HttpResponse response, NameValueCollection queryString, VirtualFileReader fileReader)
   at System.Web.Handlers.ScriptResourceHandler.ProcessRequest(HttpContext context)
   at System.Web.Handlers.ScriptResourceHandler.System.Web.IHttpHandler.ProcessRequest(HttpContext context)
   at System.Web.HttpApplication.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
   at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)


Custom event details: 

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

我的 .NET 代码中也会时不时地收到此错误，这可能是相关的：

Exception raised in GLOBAL.ASAX.Application_Error(): 'Padding is invalid and cannot be removed.' at System.Security.Cryptography.RijndaelManagedTransform.DecryptData(Byte[] inputBuffer, Int32 inputOffset, Int32 inputCount, Byte[]& outputBuffer, Int32 outputOffset, PaddingMode paddingMode, Boolean fLast)
   at System.Security.Cryptography.RijndaelManagedTransform.TransformFinalBlock(Byte[] inputBuffer, Int32 inputOffset, Int32 inputCount)
   at System.Security.Cryptography.CryptoStream.FlushFinalBlock()
   at System.Web.Configuration.MachineKeySection.EncryptOrDecryptData(Boolean fEncrypt, Byte[] buf, Byte[] modifier, Int32 start, Int32 length, IVType ivType, Boolean useValidationSymAlgo)
   at System.Web.UI.ObjectStateFormatter.Deserialize(String inputString)

【问题讨论】：

我可能在您的茶杯中看到鳄鱼，但这可能是针对您的网站执行的经典 padding oracle 攻击。首先，在为时已晚之前加密 web.config 文件中的任何敏感数据总是安全的。

【参考方案1】：

这似乎与许多人遇到的相同的 IE8 问题。似乎发生的事情是，IE8（在 IE8 呈现模式和 IE7 兼容模式下）会在 HTML 文档中间丢失 4096 个字节，并且这个丢失的数据会导致这个异常（你通常在 ScriptResource 或 WebResource 调用中看到这个） .

以下是有关该问题的 Microsoft 错误报告： https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=434997

还有很多关于这个问题的论坛、博客等帖子：

Invalid Webresource.axd parameters being generated IE 8 dropping memory pages? http://forums.asp.net/t/1373410.aspx?PageIndex=1 http://forums.asp.net/p/1409964/3085329.aspx

---

微软已对此问题作出回应：

注意是 Internet Explorer 8 中的一个错误。Internet Explorer 团队一直在调查此问题。

影响：到目前为止，我们认为该问题不会影响最终用户使用 Web 应用程序的体验；唯一的负面影响是 javascript 推测下载引擎发送的虚假/格式错误的请求。当解析器实际需要该脚本时，该脚本将被正确下载和使用。

情况：虚假请求似乎仅在某些时间情况下出现，仅当包含带有 CHARSET 指令的 Content-Type 的 META HTTP-EQUIV 标记出现在文档中时，并且仅当JavaScript SRC URL 跨越 HTTP 响应正文的第 4096 个字节。

解决方法：因此，我们目前认为可以通过使用 HTTP Content-Type 标头声明页面的 CHARSET 而不是在页面中指定它来缓解此问题。

所以，而不是放

<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=utf-8">

改为在您的 head 标签中发送以下 HTTP 响应标头：

Content-Type: text/html; charset=utf-8

请注意，HTTP 标头中的字符集规范会提高所有浏览器的性能，因为浏览器的解析器在遇到字符集声明时无需从头重新开始解析。此外，使用 HTTP 标头有助于缓解某些 XSS 攻击向量。

注意：据报道，当 META HTTP-EQUIV 不在页面上时，仍然会发生此问题。当我们进行更多调查时，我们会更新此评论。

Microsoft 于 2009 年 6 月 30 日下午 12:25 发布。

编辑： 我仍然偶尔会看到此异常，但据报告此错误已修复： http://blogs.msdn.com/b/ieinternals/archive/2010/04/01/ie8-lookahead-downloader-fixed.aspx

【参考方案2】：

我猜你正在使用 ASP.NET AJAX。我有同样的问题。偶尔我会在我的事件日志中找到这个异常，并且请求的路径是 ALWAYS ScriptResource.axd。

在 machineKey 中使用固定的validationKey 和decryptionKey 并没有解决我的问题。

根据我收集到的信息，我倾向于认为这个错误与 ViewState 无关；我的理论是，出于某种原因，某些 UA 以某种方式弄乱了 ScriptResource.axd 的“d”参数。通过手动请求有问题的路径，可以轻松复制该问题。这给出了“无效的 ViewState”异常，即使 ViewState 在这里甚至不适用。

翻阅我的日志，我发现例如：

此请求处理正常 (200)： /ScriptResource.axd?d=oFCAB7_vUyp7Hhe9lxZBz37lpoAxhfbWwwdfFy3Zd3z41W_33Y_9Dq6i10g9Q1NRCY1n0_DNg1nE6-DDbsD6r4EiuwoeDzp9mjDDfBNLb1k1&t=41df03cc

这个略有不同的请求也可以正常处理（200）： /ScriptResource.axd?d=oFCAB7_vUyp7Hhe9lxZBz37lpoAxhfbWwwdfFy3Zd3z41W_33Y_9Dq6i10g9Q1NR5ijsxQts4AfbJdACRwmQ8sHt6UAzui3spEnooPneTz01&t=41df03cc

此请求失败并返回 500 响应和 Invalid ViewState 异常： /ScriptResource.axd?d=oFCAB7_vUyp7Hhe9lxZBz37lpoAxhfbWwwdfFy3Zd3z41W_3products$ctl00$AddToCart1$id

如果仔细观察，三个请求的前几个字符都相同，但最后一个请求的最后几个字符（粗体）显然是 Control ID "products$ctl00$AddToCart1$id"（我有一个控制命名产品和 AddToCart）。我不知道这个 ID 是如何到达那里的，但就我而言，这就是导致所有这些 Invalid ViewState 异常的原因。

我不确定这是否与 OP 相同，但我注意到 Martin 的请求 URL 以“html”结尾，这对于应该是键的参数来说有点巧合。 ..

由于这个问题，我已经很头疼了。到目前为止，我遇到的最有见地的帖子是http://bytes.com/topic/asp-net/answers/861764-invalid-viewstate-system-string-decryptstringwithiv

有什么见解吗？

【讨论】：

是的，我确实注意到了请求中的战略字符，我也不知道它们来自哪里。我看过那个网址，但它并没有真正帮助，因为我所有的脚本都在 CDATA 中。

您是否使用过任何 DevExpress 或 Telerik 第三方库？我有，我认为这可能与此有关。

不。不使用 DevExpress 或 Telerik。我使用的唯一第三方库是 jQuery，以及一些插件。其余的只是纯 ASP.NET 3.5。

我们在这里重现了这个问题：下载了一个名为 Netlimiter 的工具。我将 Internet Explorer 的下载速度限制为 1 KB。在页面请求期间，我向浏览器添加了一个新 url 并导航到那里（这将停止当前请求并开始一个新请求）。我能够一遍又一遍地产生相同的错误。时机需要正确，因为我认为您需要在加载视图状态或脚本资源的确切位置中止（或切换）请求。所以这意味着它发生在慢速网络上。我怀疑它是 .net Ajax 库的错误。

这很有趣。我将不得不下载 netlimiter 并尝试一下。然而，我高度怀疑这是一个 .net 错误。此问题仅发生在 ie8 用户代理字符串中。我注意到（与论坛上的其他人一样）正在发生的事情是 ie8 正在从页面中间切出 4096 个字节。如果您查看错误中的查询字符串，您可能会注意到页面的其他部分被放入对 webresource.axd 的请求中。当我调查页面的这一部分时，总是在请求字符串中最后一个有效字符之后 4096 个字符。

【参考方案3】：

Viewstate 问题令人烦恼且令人沮丧 - 我注意到一些人在此线程中谈到了 Viewstate 问题。所以，这里有一些建议，您可以按顺序查看。

我会附和 Freddy Rios 所说的话 已经在线程中。确保 你已经硬编码了机器 钥匙。这将解决广大 这些问题中的大多数。这 重要的事情 ScriptResource 链接就是它 应该有一个 d 参数和一个 t 查询字符串中的参数。如果它 是不是还有什么问题！

不要让用户回发，直到 你完成了。你可能会做 这个用 javascript 和一点 css。从记忆中，我认为有一个 使用元标记执行此操作的方法，但是 它可能只是 IE。

我会看看是冲洗 及早回应。我会想之后 脚本管理器将是最好的。 但是你可能需要尝试一个 位。

如果您的视图状态看起来臃肿， 在 IIS 中打开 GZip 压缩。

如果你的 viewstate 真的变成了 臃肿且无法获取 GZip 压缩打开/或它有一个 不良的副作用。那么你就可以 压缩和解压缩 视图状态。 http://www.codeproject.com/KB/viewstate/ViewStateCompression.aspx

如果这仍然给你留下一个 臃肿的视图状态，你可以看看 在本地存储视图状态。 http://blog.arctus.co.uk/articles/2007/04/23/advanced-asp-net-storing-viewstate-in-a-database/ 是一个很好的起点。

【参考方案4】：

使用固定的机器密钥（即使在做单服务器时）。

当使用机器密钥的自动配置时会出现问题，每次应用程序域被回收时都会得到一个新的。这会影响视图状态验证、动态资源查询字符串解密和身份验证票证[插入机器密钥的其他用途]。

【讨论】：

我试过这个，但没有任何区别.. 即：添加了类似的内容：

@Martin 您是否首先检查过它是否正在处理几个回发？你提到你很难重现，有什么改变吗？

@Martin 我假设你这样做了，但为了确定：记住你需要为每个算法使用适当大小的密钥。

不，我没有改变任何东西，这个错误一直存在。使用大小合适的钥匙是什么意思？我刚刚用过：developmentnow.com/articles/machinekey_generator.aspx

顺便说一句，它的 .net 3.5 with SP1 on windows server 2003 SP2

【参考方案5】：

当 Viewstate 太大时，我看到过这样的问题。由于 Freddy 描述的问题，我已经看到它发生了。

我通常不喜欢使用 Viewstate 的想法。你能完全关闭 Viewstate 吗？

【讨论】：

我试图最小化视图状态，但它没有产生任何影响 .. :( 我不能完全关闭它，因为我必须重写整个应用程序，这需要很长时间 :(

【参考方案6】：

我也遇到了这个问题，我已经尝试了我找到的所有博客中提到的所有内容（固定机器密钥、视图状态大小等）。 99% 的错误记录在对 ScriptResource.axd 的请求上。我在 Win 2003 服务器上使用 .net 3.5 SP1。该应用程序托管在两台相同的并行服务器上，50/50 平衡。每个服务器都有相同的机器密钥。

通常这个错误对我来说并不重要，但是，在 3 个月的时间里，发生的趋势一直在上升。

是否有人认为此错误与未正确进行 UrlEncoded/HtmlEncoded 或 UrlDecoded 的 Viewstate 有关。视图状态中可能存在某些浏览器正在用某些编码值替换的字符子集。我不确定这是否有意义..

【讨论】：

我们在这里重现了这个问题：下载了一个名为 Netlimiter 的工具。我将 Internet Explorer 的下载速度限制为 1 KB。在页面请求期间，我向浏览器添加了一个新 url 并导航到那里（这将停止当前请求并开始一个新请求）。我能够一遍又一遍地产生相同的错误。时机需要正确，因为我认为您需要在加载视图状态或脚本资源的确切位置中止（或切换）请求。所以这意味着它发生在慢速网络上。我怀疑它是 .net Ajax 库的一个错误。

【参考方案7】：

我认为，你必须在aspx页面中使用：

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">

这解决了我的问题

【参考方案8】：

您运行的是非英语操作系统吗？

由于某些原因，“NT Authority\Network Service”的帐户名称已本地化为其他语言。 可悲的是，许多程序将帐户名称硬编码为英文名称，并且在外国版本的 Windows 上运行时找不到网络服务，从而导致事件日志中出现各种奇怪的错误。

【参考方案9】：

我刚刚将这个问题缩小到一个使用趋势科技防病毒软件的用户，并且在他于 2009 年 5 月 21 日更新他的趋势科技软件后，错误才开始出现。在此日期之前没有错误。

【参考方案10】：

问题似乎是 IE8 中的前瞻下载器。

它似乎只在相当模糊的情况下影响 IE8。它可能被忽视的原因之一是附加到 URL 的 4k 数据块通常被服务器丢弃。似乎使它更有可能发生的事情之一是网络连接速度慢。以下资源之一中的某个人指出，他只与新西兰的客户有问题。

很多人解释了两个不同的问题，其中一个在上面的问题中描述（发送到服务器的 URL 格式错误）：

http://connect.microsoft.com/VisualStudio/feedback/details/434997/invalid-webresource-axd-parameters-being-generated

解释前瞻下载器已修复的文章：

http://blogs.msdn.com/b/ieinternals/archive/2010/04/01/ie8-lookahead-downloader-fixed.aspx

KB980182 – 已修复问题的累积更新：

http://support.microsoft.com/kb/980182

注意：因为如果前瞻下载器无法检索脚本，则会自动重新下载脚本，因此应该可以改回 .axd 文件所在的旧验证模式未检查有效性并消除问题的症状：

<httpRuntime requestValidationMode="2.0" />

【讨论】：

我遇到了同样的问题，但它发生在 IE8 和 IE9 中，有什么想法吗？