14

原始问题：

我们在生成 WebResource.axd url 时遇到了一个奇怪的错误。（这似乎与相当常见的“WebRsource.axd 填充无效且无法删除”问题无关）。

我们有一个 ASP.NET 网页，它在创建时会添加对 WebResource.axd 的脚本引用。

在这种情况下，我们看到 WebResource.axd 链接偶尔会在某个时间点变成垃圾，取而代之的是看起来像 javascript 的内容。更糟糕的是，url 生成失败似乎并不一致。

在我们的例子中，链接应该（并且通常看起来像）：

/WebResource.axd?d=D-wd7RbHCvSp_p0mHAmE4g2&t=633464867255568315

一切都很好。但是，我们收到用户记录的错误......他们尝试访问的 url 看起来像（在一种情况下）：

/WebResource.axd?d=D-wd7RbHCvS/../../images/icons/Ico_resize.gif')}}function%20ShowFilter_Manufacturer(){var%20div.......

[该链接中剩余的编码 javascript 已被删除，因为不相关]

更奇怪的是，我们从同一个用户那里快速连续地获得了其中的一些，显然他正试图重新加载页面......每个 url 略有不同。

/WebResource.axd?d=D-wd7RbHCvS<garbage>
/WebResource.axd?d=D-wd7RbHCvSp<garbage>
/WebResource.axd?d=D-wd7RbHCvSp_<garbage>

在某些情况下，垃圾是用 JavaScript 编码的，我看到了 url 的一部分……完全为空的参数字符串……我没有看到明显的模式。

顺便说一句，如果它是相关的，应该注意的是，我不相信这个 WebResource 不是股票 WebResource 之外的任何东西，当页面上包含某些功能时，.NET 会自动包含它......在这种情况下，一个字段验证器。查看实际 WebResource.axd 的内容会发现一组看起来非常标准的 Javascript 函数，这些函数似乎旨在处理通用 .NET 事件。不是我们创造的任何东西。

有没有人见过这样的事情？（或者更好的是，有没有人理解为什么会发生这种情况，并想出一种方法来消除它？）

编辑 0：一些附加信息：

第 1 项：针对一个答案，我们确保我们的脚本用 CDATA 标记封装，因为我们的 doctype 是 xhtml 过渡：

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

不幸的是，虽然我们寄予厚望，但它似乎并没有解决问题。我们在 IE 8 作为浏览器时更经常注意到这一点，这会让人相信这是与浏览器相关的想法......也许是浏览器解析流的方式......但是为什么我们会得到微妙的不同响应在随后的尝试中让我感到困惑。

第 2 项：事实证明，省略的部分似乎是相当规则大小的块。有人报告说他看到 1k 或 4k 块丢失，我（到目前为止……我只看过两个案例）会同意（我的都丢失了 4096 字节的数据）。

4

7 回答 7

7

根据这篇文章：

http://bytes.com/topic/asp-net/answers/861764-invalid-viewstate-system-string-decryptstringwithiv

似乎问题是由于未指定文档类型时浏览器呈现页面的方式不同引起的。

这是我在这个主题上发现的另一篇有趣的帖子，但仍然不是解决方案：

http://blog.aproductofsociety.org/?p=11

在上面的页面上，它在评论中有“Response.Cache.SetNoStore()”作为可能的解决方案，我接下来会试试这个，看看它是否有帮助。

于 2009-02-04T15:03:11.583 回答
5

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

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

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

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

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

所以，而不是把

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

相反，在您的 head 标记中，发送以下 HTTP 响应标头：

内容类型：文本/html；字符集=utf-8

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

注意：有报道称，当 META HTTP-EQUIV 不在页面上时，仍然会发生此问题。当我们进行更多调查时，我们将更新此评论。Microsoft 于 2009 年 6 月 30 日下午 12:25 发布

于 2009-07-06T13:48:55.127 回答
2

我来自 ASP.NET 团队——我们正在寻找愿意与我们合作研究此问题的客户。如果有人能够通过请求自己的页面和检查日志来可靠地重现问题，并且愿意与我们的支持小组合作，请回复或直接给我发送消息。谢谢！

于 2009-06-05T19:15:47.737 回答
1

您正在针对哪个版本的 .NET 进行编译？如果您将构建更改为针对较旧或较新版本构建会发生什么？（不确定这是否会做任何事情，但值得一试）

如果它仍然发生，我认为你应该在Microsoft Connect上发布一个关于它的错误。他们应该很快就会回到你身边。

于 2009-04-24T07:02:54.303 回答
1

您是否有任何在 Web 配置中注册的 HttpHandlers 或 Modules 在将呈现的 HTML 发送给用户之前对其进行修改？

这些通常可以是：

  • 缩小 JS 和 CSS
  • 确保 HTML 有效

也许值得一瞧。

于 2009-04-24T08:25:32.797 回答
0

这是一篇旧帖子......但我通过谷歌搜索发现并提醒我这个......

http://www.troyhunt.com/2010/09/fear-uncertainty-and-and-padding-oracle.html

会不会有关系？

于 2010-09-27T00:31:42.073 回答
0

微软最终修复了这个问题：

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

于 2013-02-01T21:47:26.277 回答