问题标签 [ms11-100]

据 Slashdot 报道，微软今天发布了 ASP.NET 更新以修复哈希冲突攻击。（在链接的 Technet 页面上列为“哈希表中的冲突可能导致 DoS 漏洞 - CVE-2011-3414”。）

问题在于 POST 数据被转换为使用已知散列算法的散列表。如果攻击者通过制作包含大量冲突的请求来使用它，他很容易导致拒绝服务。

有谁知道这个更新究竟是如何解决这个问题的？

Microsoft 最近 (12-29-2011) 发布了一个更新，以解决 .NET Framework 中的几个严重安全漏洞。MS11-100引入的修复之一暂时缓解了涉及哈希表冲突的潜在 DoS 攻击。看来此修复程序会破坏包含大量 POST 数据的页面。在我们的例子中，在具有非常大的复选框列表的页面上。为什么会这样？

一些非官方消息来源似乎表明 MS11-100 对回发项目设置了 500 个限制。我找不到证实这一点的 Microsoft 消息来源。我知道 View State 和其他框架功能占用了一些限制。是否有任何配置设置可以控制这个新限制？我们可以放弃使用复选框，但它对我们的特定情况非常有效。我们还想应用补丁，因为它可以防止其他一些令人讨厌的事情。

讨论 500 限制的非官方消息来源：

该公告通过限制可以为单个 HTTP POST 请求提交的变量数量来修复 DOS 攻击向量。默认限制为 500，这对于正常的 Web 应用程序来说应该足够了，但仍然足够低以抵消德国安全研究人员所描述的攻击。

编辑：带有限制示例的源代码（似乎是 1,000，而不是 500）创建标准 MVC 应用程序并将以下代码添加到主索引视图：

此代码在补丁之前有效。之后就不行了。错误是：

[InvalidOperationException：由于对象的当前状态，操作无效。]
System.Web.HttpValueCollection.ThrowIfMaxHttpCollectionKeysExceeded() +82 System.Web.HttpValueCollection.FillFromEncodedBytes(Byte[] bytes, Encoding encoding) +111
System.Web。 HttpRequest.FillInFormCollection() +307

可能重复：
ASP.NET、MS11-100 和 POST

应用 Microsoft 安全公告 MS11-100 中的更新后，我们网站上的某些表单停止工作。异常表示“由于对象的当前状态，操作无效。” 它还说“[HttpException (0x80004005): The URL-encoded form data is not valid.]”我们没有更改任何代码？？

After updating our systems with the recently released asp.net vulnerability patch ms11-100, we found that some of our pages started failing with the exception "[HttpException (0x80004005): The URL-encoded form data is not valid.]" This is covered in the asp.net forums here:

http://forums.asp.net/t/1754512.aspx/1?Microsoft+security+bulletin+MS11+100+breaking+our+site

and on stackoverflow here:

ASP.NET MS11-100: how can I change the limit on the maximum number of posted form values?

What I tried to attempt is to limit the changes suggested thereby the attack area to the specific page by moving that page to it's own folder, so that I can have a specific web.config in that folder with the setting of aspnet:MaxHttpCollectionKeys having a value larger than the default of 1000.

I found that unless I specify this setting in the web.config in the root folder, this setting did not take effect. It seemed like asp.net just ignored the setting when it was in the web.config in the new folder for the page.

Is there something else I need to do to make this happen? Or is it not possible at all because of the nature of the setting?