这个新的ASP.NET安全漏洞有多严重，我该如何解决这个问题？
我刚刚在网上读到了一个新发现的ASP.NET安全漏洞。 你可以在这里阅读细节。
问题在于ASP.NET实现AESencryptionalgorithm的方式，以保护这些应用程序在用户会话期间生成的用于存储信息的cookie的完整性。
这有些模糊，但是这是一个更可怕的部分：
攻击的第一阶段需要几千个请求，但一旦攻击成功，攻击者获得密钥，就完全隐身了。所需的密码知识是非常基础的。
总而言之，我对安全/密码学知之甚less，不知道这是否真的如此严重。
那么，所有的ASP.NET开发人员都应该担心这种技术可以在几秒钟内拥有任何ASP.NET网站 ？
这个问题如何影响一般的ASP.NET开发人员？ 它会影响我们吗？ 在现实生活中，这个漏洞有什么后果？ 最后：是否有一些解决方法可以防止此漏洞？
感谢您的回答！
编辑：让我总结我得到的答复
所以这基本上是一种“填充甲骨文”式的攻击。 @Sri对这种types的攻击是什么意思提供了一个很好的解释。 这是一个令人震惊的video关于这个问题！
关于这个漏洞的严重性：是的，这确实是严重的。 它让攻击者了解应用程序的机器密钥。 因此，他可以做一些非常不想要的事情。
- 在应用程序的机器密钥的刺激下，攻击者可以解密authenticationcookie。
- 更糟的是，他可以用任何用户的名字来生成authenticationcookie 。 因此，他可以在网站上出现任何人。 该应用程序无法区分你或黑客谁产生身份validationcookie与你自己的名字。
- 它也可以让他解密（也生成） 会话cookie ，虽然这不像以前那样危险。
- 不太严重：他可以解密encryption的ViewState页面。 （如果您使用ViewState存储有信心的数据，那么不应该这样做！）
- 非常令人意想不到 ：凭借机器密钥的知识，攻击者可以从您的Web应用程序下载任何任意文件，甚至那些通常无法下载的文件！ （包括Web.Config等）
这里有一些我没有解决的问题，但有助于提高Web应用程序的安全性。
- 您可以使用受保护的configuration来encryption敏感数据
- 使用HTTP仅Cookie
- 防止DoS攻击
现在，我们来关注这个问题。
- Scott Guthrie在他的博客上发表了一篇关于它的文章
- ScottGu的关于漏洞的FAQ博客文章
- ScottGu关于漏洞的更新
- 微软有一个关于它的安全公告
- 了解漏洞
- 有关该漏洞的其他信息
解决scheme
- 启用customErrors并创build一个所有错误都redirect到的错误页面。 是的， 即使是404s 。 （ScottGu说，区分404s和500s对于这种攻击是必不可less的。）另外，在你的
Application_Error或Error.aspx放置一些随机延迟的代码。 （生成一个随机数字，并使用Thread.Sleep睡了这么长时间。）这将使攻击者无法确定您的服务器上发生了什么。 - 有些人build议切换回3DES。 从理论上说，如果你不使用AES，你不会遇到AES实现中的安全弱点。 事实certificate，这是不build议的 。
一些其他的想法
- 似乎并不是 每个人都认为解决方法是足够好的。
感谢所有回答我的问题的人。 我不仅从这个问题上了解了很多，而且从整体上了解了networking安全。 我标记@ Mikael的答案已被接受，但其他答案也非常有用。
我该怎么做才能保护自己？
[2010-09-29更新]
微软安全公告
知识库文章参考修复
ScottGu有下载链接
[2010-09-25更新]
虽然我们正在等待修复， 但是ScottGu昨天公布了一个关于如何添加一个额外的步骤来保护您的网站的自定义URLScan规则的更新。
基本上确保你提供了一个自定义的错误页面，这样攻击者就不会遇到内部的.Net错误，在发布/生产模式下，你总是应该这样做。
另外，在错误页面添加一个随机时间睡眠，以防止攻击者为响应增加攻击信息。
在web.config
<configuration> <location allowOverride="false"> <system.web> <customErrors mode="On" defaultRedirect="~/error.html" /> </system.web> </location> </configuration>
这会将任何错误redirect到以200状态码返回的自定义页面。 这样攻击者就无法查看错误代码或错误信息以获取进一步攻击所需的信息。
设置customErrors mode="RemoteOnly"也是安全的，因为这将redirect“真实”客户端。 只有从本地主机浏览将显示内部.Net错误。
重要的部分是确保所有错误都configuration为返回相同的错误页面。 这要求您在<customErrors>部分显式设置defaultRedirect属性，并确保不设置每个状态代码。
有什么风险？
如果攻击者设法使用上述漏洞，他/她可以从您的Web应用程序中下载内部文件。 通常情况下，web.config是一个目标，可能包含敏感信息，如数据库连接string中的login信息，甚至可能链接到一个自动化的sql-express数据库，而您不希望某人获得该数据库。 但是，如果您遵循最佳做法，则使用“ 受保护的configuration”来encryptionweb.config中的所有敏感数据。
链接到引用
请访问http://www.microsoft.com/technet/security/advisory/2416728.mspx阅读有关此漏洞的微软官方评论。; 具体的“解决方法”部分是关于这个问题的实现细节。
另外还有一些关于ScottGu博客的信息，包括一个脚本，用于在您的Web服务器上查找易受攻击的ASP.Net应用程序。
有关“了解Padding Oracle攻击”的解释，请阅读@ sri的答案 。
文章评论：
Rizzo和Duong针对ASP.NET应用程序实施的攻击要求网站上的encryption实现具有一个oracle，当发送密文时，不仅可以解密文本，还可以向发件人发送关于密文中的填充是有效的 。
如果填充无效，则发件人收到的错误消息将提供有关网站解密过程工作方式的一些信息。
为了使攻击行得通，以下内容必须是正确的：
- 您的应用程序必须提供有关填充无效的错误消息。
- 有人必须篡改您的encryption的cookie或视图状态
因此，如果您在应用程序中返回人类可读的错误消息，例如“出错了，请重试”，那么您应该很安全。 阅读一下关于文章的评论也提供了有价值的信息。
- 将会话ID存储在encryption的cookie中
- 将会话状态下的真实数据存储（保存在数据库中）
- 当用户信息错误之前添加一个随机的等待，然后返回错误，所以你不能计时
这样，被劫持的cookie只能用于检索最有可能不再存在或失效的会话。
看看Ekoparty会议上实际发表的内容会很有趣，但现在我并不太担心这个漏洞。
了解填充Oracle攻击
让我们假设您的应用程序接受一个encryption的string作为参数 – 无论参数是一个cookie，一个url参数或其他东西都不重要。 当应用程序试图解码它时，有三种可能的结果 –
-
结果1 ：encryption的string解密正确，应用程序能够理解它。 这意味着，如果encryption的string是一个10位数的帐号，解密后应用程序发现像“1234567890”而不是“abcd1213ef”
-
结果2 ：填充是正确的，但解密后得到的string是乱码，该应用程序无法理解。 例如，该string解密为“abcd1213ef”，但应用程序只期待数字。 大多数应用程序将显示一条消息，如“无效帐号”。
-
结果3 ：填充不正确，应用程序抛出某种错误信息。 大多数应用程序将显示一个像“发生了一些错误”的通用信息。
为了使Padding Oracle攻击成功，攻击者必须能够发出数千个请求， 并且必须能够将响应分类到上述三个桶之一中，而不会出错。
如果满足这两个条件，攻击者最终可以解密该消息，然后用他希望的任何方法对其进行重新encryption。 它只是一个时间问题。
可以做些什么来预防呢？
-
最简单的事情 – 任何敏感的东西永远不会被发送到客户端，encryption或不encryption。 保持在服务器上。
-
确保上面列表中的结果2和结果3与攻击者完全相同 。 应该没有办法找出另一个。 然而，这并不是那么容易，攻击者可以使用某种定时攻击来区分。
-
作为最后一道防线，有一个Web应用程序防火墙。 填充oracle攻击需要做几个看起来几乎相似的请求（每次改变一个位），所以WAF应该可以捕获并阻止这样的请求。
PS Padding Oracle攻击的一个很好的解释可以在这篇博客文章中find。 免责声明：它不是我的博客。
从我读到现在…
这种攻击可以让某人解密嗅到的cookie，这些cookie可能包含诸如银行余额等有价值的数据
他们需要已经login的用户的encryption的cookie，在任何帐户。 他们还需要在cookies中查找数据 – 我希望开发人员不要将关键数据存储在cookie中:)。 有一种方法，我有下面不让asp.net存储数据在logincookie。
如果某人不掌握浏览器数据，那么如何获得在线用户的cookie？ 或者嗅探IP数据包？
防止这种情况的一种方法是不允许cookies在没有sslencryption的情况下传输。
<httpCookies httpOnlyCookies="true" requireSSL="true" />
还有一个措施是防止在Cookie中存储angular色。
<roleManager enabled="true" cacheRolesInCookie="false">
现在关于常规页面不安全的cookie，这需要更多的思考，你留下了你的用户做什么，什么不是，你如何相信他，你可以做什么额外的检查（例如，如果你看到在IP上的变化，可能会停止信任他，直到从安全页面login）。
参考：
一些黑客可以从用户那里窃取cookie，并在网站上用这个名字login？
如何检查来自哪里的攻击，而不是回报信息。 我在这里写了一个简单的方法来防止填充是无效的，并在同一时间logging下来追踪攻击者： CryptographicException：填充是无效的，不能被删除和视图状态validation失败
跟踪攻击者的方法是检查填充是否无效。 通过一个简单的程序，你可以跟踪他们，并阻止他们 – 他们需要在您的网页上的数千个电话find钥匙！
更新1。
我已经下载了这个工具，假设find了KEY并解密了数据，并且正如我在上面的代码中所说的那样检查视图状态 。 从我的testing中，这个工具还有很多需要解决的问题，比如不能像扫描压缩的视图状态那样扫描，而且在我的testing中崩溃。
如果有人尝试使用这个工具或者这个方法，上面的代码可以跟踪它们，你可以用简单的代码来阻止它们离开你的页面，比如这个“防止拒绝服务（DOS）” ，或者像这样的代码来防止拒绝的服务 。
更新2
从我现在看到的东西看来， 唯一真正需要的就是不要提供有关错误的信息 ，只需放置一个自定义错误页面，如果你喜欢，你可以创build一个随机的延迟到这个页面。
在这个问题上一个非常有趣的video 。
所以上述所有的更多的措施，为更多的保护，但不是100％的这个特定问题的必要条件。 例如要使用ssl cookie解决了snif问题，不cachingcookie中的angular色，不发送和取回大的cookie，并避免一些已经准备好破解代码，只是把pipe理angular色放在他的cookies。
视图状态跟踪它的一个更多的措施来发现攻击。
这是MS的回应。 这一切归结为“使用自定义错误页面”，你不会放弃任何线索。
编辑
这里是一些来自scottgu的更详细的信息。
自定义IHttpModule而不是customErrors受到影响？
问：我没有在我的web.config中声明的元素，而是在段内部有一个IHttpModule。 该模块logging错误并redirect到search页面（对于404）或错误页面（对于500）。 我是脆弱的吗？
答：我会build议暂时更新模块，以便总是redirect到search页面。 这种攻击的方式之一就是寻找404和500错误之间的区别。 总是返回相同的HTTP代码并将它们发送到相同的地方是帮助阻止它的一种方法。
请注意，当修补程序出来解决这个问题时，您不需要这样做（并且可以恢复到旧的行为）。 但现在我build议不要区分404和500之间的客户端。
我可以继续对404和500错误使用不同的错误吗？
问：我认为，除了默认的错误redirect之外，我们还可以定义一个自定义404页面，而不违反上述原则？
答：不可以 – 直到我们发布一个修补程序，我们推荐上述解决方法，使所有错误均匀化。 这种攻击的方式之一就是寻找404和500错误之间的区别。 总是返回相同的HTTP代码并将它们发送到相同的地方是帮助阻止它的一种方法。
请注意，当修补程序出来解决这个问题时，您不需要这样做（并且可以恢复到旧的行为）。 但是现在你不应该把404和500之间的区分给客户。
这是如何暴露web.config？
问：这是如何暴露web.config的？ 这似乎只能解密ViewState，是否还有另一个相关的漏洞，也允许信息公开？ 是否有白皮书详细介绍了攻击，以更好地解释发生了什么？
答：公开中显示的攻击依赖于ASP.NET中的一项function，该function允许下载文件（通常是javascript和css），并使用作为请求一部分发送的密钥进行保护。 不幸的是，如果您能够伪造一个密钥，则可以使用此function下载应用程序的web.config文件（但不是应用程序之外的文件）。 我们显然会为此发布补丁 – 直到上面的解决方法closures攻击vector。
国际海事组织对此没有全面的预防，需要根据具体情况进行处理：
http://www.onpreinit.com/2010/09/aspnet-vulnerability-workaround-flawed.html
一些重要的联系：
- MS'安全咨询2416728 （这是官方信息）
- 来自MS安全研究和防御团队的额外信息
- “了解ASP.NET漏洞”（2010-09-17）
- “有关ASP.NET漏洞的其他信息”（2010-09-20）
- Scott Gu：“重要：ASP.NET安全漏洞”（2010-09-18）
[回答这个问题的严肃性（其他答案已经公布和解决方法）。]
被攻击的关键是用来保护视图状态和会话cookie。 通常情况下，这个密钥是由ASP.NET每个新的Web应用程序实例在内部生成的。 这将限制工作人员进程寿命的损害范围，当然对于繁忙的应用程序，这可能是几天（即不是极限）。 在此期间，攻击者可以将值更改（或注入）到ViewState中并更改其会话。
更严重的是，如果您希望会话能够跨越工作进程生命周期，或者允许web farm（即场中的所有实例都可以处理任何用户会话），则需要对关键字进行硬编码，这可以在web.config完成：
[...] <system.web> <machineKey decryption="AES" validation="SHA1" decryptionKey="57726C59BA73E8A4E95E47F4BC9FB2DD" validationKey="158B6D89EE90A814874F1B3129ED00FB8FD34DD3" />
那些当然是新创build的密钥，我使用下面的PowerShell来访问Windowsencryption随机数生成器：
$rng = New-Object "System.Security.Cryptography.RNGCryptoServiceProvider" $bytes = [Array]::CreateInstance([byte], 20) $rng.GetBytes($bytes) $bytes | ForEach-Object -begin { $s = "" } -process { $s = $s + ("{0:X2}" -f $_) } -end { $s}
（使用20的数组长度进行validation，16使用解密密钥。）
除了修改公共错误页面以不泄漏特定的错误外，现在看起来是更改上述键值的好时机（或者如果已经运行了一段时间，循环工作进程）。
[编辑2010-09-21：添加链接到顶部]
经过对这个问题的额外研究之后，我只是在博客上发表了我的全部观点。 我认为它清楚为什么他们正在伪造一个auth cookie。
只想直接得到一些事实：
- 攻击不会让你直接拿到机器钥匙。 也就是说，它非常像它，因为它允许解密消息，并修改重新encryption新的。
- 获得实际密钥的方式是通过使用它们修改1中的re / encrypt的能力并获取web.config。 不幸的是，为什么有些人把这些键放在网站级别的web.config中（不同的讨论），并且在示例video中，他们受益于DotnetNuke的默认值。
- 得到web.config都指出他们正在使用webresources.axd和/或scriptresources.axd。 我认为这些工作只与embedded式资源，但似乎并非如此。
- 如果应用程序是asp.net MVC，我们并不需要webresources.axd和/或scriptresources.axd，因此可以closures这些应用程序。 我们也不使用viewstate。 这就是说，它不清楚，如果任何其他的asp.netfunction提供不同的信息与解决方法就地即我不知道如果填充提供了错误的无效结果，同时填充有效的结果在被忽略的身份validation票（不知道如果不是这样的话）…同样的分析应该适用于会话cookie。
- asp.net会员提供者在cookie中cachingangular色，closures。
大约1，afaikencryption的消息不能100％任意地需要容忍在消息的某个地方的一小块垃圾，因为在消息中有1块解密值不能被控制。
最后我想说的是，这个问题是ms在这种情况下没有遵循自己的指导的结果：一个function依赖于发送给客户端的东西是防篡改的。
更多关于：
我不知道如果填充填充有效的结果在被忽略的身份validation票证（不知道是否它的情况下）填充给出错误无效的结果…同样的分析应该适用于会话cookie。
auth cookie是经过签名的，如果他们没有得到实际的密钥（如他们在伪造auth cookie之前在video中所做的那样），他们不应该能够生成签名的cookie。
正如Aristos所提到的，对于Cookie中的会话ID，对于用户会话来说是随机的，所以必须从具有目标安全级别的用户中嗅探，并在该会话处于活动状态时破解。 即使如此，如果您依赖于身份validation来分配/授权用户操作，那么影响将是最小的/这将取决于该应用程序中使用的会话的很多。
此更新的补丁已在Windows Update上发布： http : //weblogs.asp.net/scottgu/archive/2010/09/30/asp-net-security-fix-now-on-windows-update.aspx
Asp.Net MVC也受到这个问题的影响（就像Sharepoint，…）
我已经在这里介绍了MVC的修复： ASP.NET MVC容易受到Oracle填充攻击的影响吗？
