我刚刚在网上读到有关 ASP.NET 中新发现的安全漏洞的信息。 You can read the details here.
The problem lies in the way that ASP.NET implements the AES encryption algorithm to protect the integrity of the cookies these applications generate to store information during user sessions.
这有点模糊，但这里有一个更可怕的部分:
The first stage of the attack takes a few thousand requests, but once it succeeds and the attacker gets the secret keys, it's totally stealthy.The cryptographic knowledge required is very basic.
总而言之，我对安全/密码学主题还不够熟悉，不知道这是否真的那么严重。
那么，所有 ASP.NET 开发人员都应该担心这种可以在几秒钟内拥有任何 ASP.NET 网站的技术吗？
此问题对普通 ASP.NET 开发人员有何影响？它对我们有影响吗？ 在现实生活中，这个漏洞会造成什么后果？最后:是否有一些解决方法可以防止此漏洞？
感谢您的回答!
<小时/>编辑:让我总结一下我得到的回复
所以，这基本上是一种“填充预言”类型的攻击。 @Sri很好地解释了这种类型的攻击的含义。 Here is a shocking video about the issue!
关于该漏洞的严重性:是的，确实很严重。 它让攻击者能够了解应用程序的机器 key 。因此，他可以做一些非常不需要的事情。
- 掌握应用的机器 key 后，攻击者可以解密身份验证 Cookie。
- 更糟糕的是，他可以使用任何用户的名称生成身份验证 cookie。因此，他可以以任何人的身份出现在网站上。该应用程序无法区分您或使用您的名字生成身份验证 cookie 的黑客。
- 它还可以让他解密(并生成) session cookie，尽管这不像前一个那样危险。
- 没那么严重:他可以解密页面的加密ViewState。 (如果您使用 ViewState 存储 secret 数据，则无论如何都不应该这样做!)
- 非常出乎意料:凭借机器 key 的知识，攻击者可以从您的网络应用程序下载任何任意文件，甚至是那些通常无法下载的文件! (包括Web.Config等)
这里有一些我得到的良好实践，不能解决问题，但有助于提高 Web 应用程序的总体安全性。
现在，让我们重点讨论这个问题。
- Scott Guthrie published an entry about it on his blog
- ScottGu's FAQ blog post about the vulnerability
- ScottGu's update on the vulnerability
- Microsoft has a security advisory about it
- Understanding the vulnerability
- Additional information about the vulnerability
解决办法
- 启用自定义错误并创建一个错误页面，所有错误都会重定向到该页面。是的，甚至是 404。 (ScottGu 说区分 404 和 500 对于这种攻击至关重要。)此外，在您的
Application_Error或Error.aspx中放入一些产生随机延迟的代码。 (生成一个随机数，并使用 Thread.Sleep 休眠那么长时间。)这将使攻击者无法确定您的服务器上到底发生了什么。 - 有些人建议改回 3DES。理论上，如果您不使用 AES，则不会遇到 AES 实现中的安全漏洞。事实证明，根本不建议这样做。
其他一些想法
感谢所有回答我问题的人。我不仅学到了很多关于这个问题的知识，而且学到了很多关于网络安全的知识。我将 @Mikael 的答案标记为已接受，但其他答案也非常有用。
最佳答案
我应该怎样做才能保护自己？
[更新2010-09-29]
KB Article with reference to the fix
ScottGu有下载链接
[更新2010-09-25]
当我们等待修复时，昨天 ScottGu postet an update了解如何添加额外步骤以使用自定义 URLScan 规则保护您的网站。
<小时/> 基本上确保您提供自定义错误页面，以便攻击者不会暴露于内部 .Net 错误，而在发布/生产模式下您始终应该这样做。另外在错误页面添加随机时间休眠，防止攻击者 timing the responses添加攻击信息。
在 web.config 中
<configuration>
<location allowOverride="false">
<system.web>
<customErrors mode="On" defaultRedirect="~/error.html" />
</system.web>
</location>
</configuration>
这会将任何错误重定向到返回 200 状态代码的自定义页面。这样攻击者就无法查看错误代码或错误信息来获取进一步攻击所需的信息。
设置 customErrors mode="RemoteOnly" 也是安全的，因为这将重定向“真实”客户端。只有从本地主机浏览才会显示内部 .Net 错误。
重要的是确保所有错误都配置为返回相同的错误页面。这需要您显式设置 defaultRedirect <customErrors> 上的属性部分并确保未设置每个状态代码。
有什么危险？
如果攻击者设法利用上述漏洞，他/她可以从您的 Web 应用程序中下载内部文件。通常，web.config 是一个目标，可能包含敏感信息，例如数据库连接字符串中的登录信息，甚至链接到您不希望有人获取的自动 sql-express 数据库。但如果您遵循最佳实践，则可以使用 Protected Configuration加密 web.config 中的所有敏感数据。
引用链接
阅读 Microsoft 关于该漏洞的官方评论:http://www.microsoft.com/technet/security/advisory/2416728.mspx 。具体来说，“解决方法”部分提供了有关此问题的实现细节。
还有一些关于 ScottGu's 的信息博客，包括 script在您的 Web 服务器上查找易受攻击的 ASP.Net 应用程序。
有关“了解 Padding Oracle 攻击”的说明，请阅读 @sri's answer .
<小时/>文章评论:
The attack that Rizzo and Duong have implemented against ASP.NET apps requires that the crypto implementation on the Web site have an oracle that, when sent ciphertext, will not only decrypt the text but give the sender a message about whether the padding in the ciphertext is valid.
If the padding is invalid, the error message that the sender gets will give him some information about the way that the site's decryption process works.
为了使攻击起作用，必须满足以下条件:
- 您的应用程序必须给出有关填充无效的错误消息。
- 有人必须篡改您的加密 Cookie 或 View 状态
因此，如果您在应用中返回人类可读的错误消息，例如“出现问题，请重试”，那么您应该非常安全。阅读一下文章的评论也可以提供有值(value)的信息。
- 将 session ID 存储在加密 Cookie 中
- 将真实数据存储在 session 状态中(保存在数据库中)
- 在返回错误之前添加用户信息错误时的随机等待，这样就无法计时
这样，被劫持的 cookie 只能用于检索很可能不再存在或失效的 session 。
看看 Ekoparty session 上实际展示的内容将会很有趣，但现在我不太担心这个漏洞。
关于asp.net - 这个新的 ASP.NET 安全漏洞有多严重？我该如何解决它？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/3720720/