1. 首页
  2. 问题
  3. 这个新的 ASP.NET 安全漏洞有多严重，我该如何解决？
小编典典

这个新的 ASP.NET 安全漏洞有多严重，我该如何解决？

all

我刚刚在网上阅读了有关 ASP.NET
中新发现的安全漏洞的信息。您可以在此处阅读详细信息。

问题在于 ASP.NET 实现 AES 加密算法以保护这些应用程序在用户会话期间存储信息而生成的 cookie 的完整性的方式。

这有点模糊，但这里有一个更可怕的部分：

攻击的第一阶段需要几千个请求，但一旦成功并且攻击者获得了密钥，它就完全是隐秘的。所需的密码知识非常基础。

总而言之，我对安全/密码学主题不够熟悉，不知道这是否真的那么严重。

那么，所有 ASP.NET 开发人员是否应该害怕这种 可以在几秒钟内拥有任何 ASP.NET 网站的 技术呢？

这个问题对普通的 ASP.NET 开发人员有何影响？它对我们有影响吗？在现实生活中，这个漏洞的后果是什么？最后：是否有一些解决方法可以防止此漏洞？

感谢您的回答！

编辑：让我总结一下我得到的回复

所以，这基本上是一种“填充预言”类型的攻击。@Sri很好地解释了这种攻击的含义。

了解填充 Oracle 攻击

让我们假设您的应用程序接受加密字符串作为参数——参数是 cookie、url 参数还是其他无关紧要的东西。当应用程序尝试对其进行解码时，有 3 种可能的结果 -

  1. 结果 1：加密字符串正确解密，应用程序能够理解它。意思是，如果加密的字符串是一个 10 位数的帐号，则在解密后应用程序会发现类似“1234567890”而不是“abcd1213ef”的内容
  2. 结果 2：填充是正确的，但解密后获得的字符串是应用程序无法理解的乱码。例如，字符串解密为“abcd1213ef”，但应用程序只需要数字。大多数应用程序都会显示“无效帐号”之类的消息。
  3. 结果 3：填充不正确，应用程序抛出了某种错误消息。大多数应用程序会显示一条通用消息，例如“发生了一些错误”。

为了使 Padding Oracle 攻击成功，攻击者必须能够发出数千个请求，并且必须能够将响应分类为上述 3 个桶之一而不会出错。

如果满足这两个条件，攻击者最终可以解密消息，然后用他想要的任何方式重新加密。这只是时间问题。

可以做些什么来预防它？

  1. 最简单的事情 - 任何敏感的东西都不应该发送给客户端，加密或不加密。保存在服务器上。
  2. 确保上述列表中的结果 2 和结果 3 在攻击者看来完全相同。应该没有办法从另一个中找出一个。然而，这并不是那么容易——攻击者可以使用某种定时攻击来区分。
  3. 作为最后一道防线，拥有一个 Web 应用程序防火墙。padding oracle 攻击需要发出几个看起来几乎相似的请求（一次更改一位），因此 WAF 应该可以捕获并阻止此类请求。

关于这个漏洞的严重性：是的，确实很严重。 它让攻击者能够了解应用程序的机器密钥。 因此，他可以做一些 非常 不受欢迎的事情。

  • 在拥有应用程序的机器密钥后，攻击者可以解密身份验证 cookie。
  • 更糟糕的是，他可以使用任何用户的名称 生成身份验证 cookie 。 因此，他可以在网站上以任何人的身份出现。该应用程序无法区分您还是为自己生成了带有您的姓名的身份验证 cookie 的黑客。
  • 它还允许他解密（并生成） 会话 cookie ，尽管这不像前一个那样危险。
  • 没那么严重：他可以解密页面的加密 ViewState。（如果您使用 ViewState 来存储机密数据，则无论如何都不应该这样做！）
  • 非常出乎意料 ：通过机器密钥的知识，攻击者 可以从您的 Web 应用程序中下载 任意文件，甚至是那些通常无法下载的文件！（包括 Web.Config 等）

这是我得到的一堆好的做法， 它们并 不能解决问题，但有助于提高 Web 应用程序的一般安全性。

现在，让我们专注于这个问题。

解决方案

  • 启用 customErrors 并创建一个将 所有错误 重定向到的错误页面。是的， 甚至是 404s 。（ScottGu 说区分 404s 和 500s 对于这种攻击是必不可少的。）另外，在你的Application_Error或者Error.aspx放入一些随机延迟的代码。（生成一个随机数，并使用 Thread.Sleep 休眠那么久。）这将使攻击者无法确定您的服务器上究竟发生了什么。
  • 有些人建议切换回 3DES。理论上，如果不使用 AES，就不会遇到 AES 实现中的安全漏洞。事实证明，这根本 不推荐 。

其他一些想法

感谢所有回答我问题的人。我不仅学到了很多关于这个问题的知识，而且学到了很多关于网络安全的知识。我将@Mikael 的答案标记为已接受，但其他答案也非常有用。


阅读 88

收藏
2022-07-18

共1个答案

小编典典

我该怎么做才能保护自己？

[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>

这会将任何错误重定向到返回 200 状态代码的自定义页面。这样，攻击者就无法查看错误代码或错误信息以获取进一步攻击所需的信息。

设置 也是安全的customErrors mode="RemoteOnly"，因为这将重定向“真实”客户端。只有从 localhost 浏览才会显示内部
.Net 错误。

重要的部分是确保所有错误都配置为返回相同的错误页面。这要求您明确设置该部分的defaultRedirect属性<customErrors>并确保未设置每个状态代码。

有什么风险？

如果攻击者设法使用上述漏洞，他/她可以从您的 Web 应用程序中下载内部文件。通常 web.config
是一个目标，并且可能包含敏感信息，例如数据库连接字符串中的登录信息，甚至链接到您不希望有人掌握的自动 sql-express
数据库。但是，如果您遵循最佳实践，您可以使用受保护的配置来加密 web.config 中的所有敏感数据。

参考文献链接

在http://www.microsoft.com/technet/security/advisory/2416728.mspx上阅读
Microsoft 关于该漏洞的官方评论。特别是有关此问题的实施细节的“解决方法”部分。

还有一些关于ScottGu博客的信息，包括在您的 Web 服务器上查找易受攻击的 ASP.Net
应用程序的脚本。

文章评论：

Rizzo 和 Duong 对 ASP.NET 应用程序实施的攻击要求网站上的加密实施有一个预言机，当发送密文时，它不仅会解密文本，还会
向发送者发送一条消息，说明密文中是否有填充是有效的 。

如果填充无效，发件人收到的错误消息将为他提供有关站点解密过程工作方式的一些信息。

为了使攻击起作用，必须满足以下条件：

  • 您的应用程序必须给出有关填充无效的错误消息。
  • 必须有人篡改您的加密 cookie 或视图状态

因此，如果您在应用程序中返回人类可读的错误消息，例如 “出现问题，请重试”， 那么您应该是非常安全的。阅读一些关于文章的评论也可以提供有价值的信息。

  • 在加密的 cookie 中存储会话 ID
  • 以会话状态存储真实数据（保存在数据库中）
  • 用户信息错误时添加随机等待返回错误，所以无法计时

这样，被劫持的 cookie 只能用于检索很可能不再存在或失效的会话。

看看 Ekoparty 会议上实际展示的内容会很有趣，但现在我不太担心这个漏洞。

2022-07-18