相关疑难解决方法(0)

我究竟做错了什么？

326
推荐指数

6
解决办法

31万
查看次数

我刚刚在网上看到了ASP.NET中新发现的安全漏洞.你可以在这里阅读详细信息.

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

这有点模糊,但这里有一个更令人恐惧的部分:

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

总而言之,我对安全性/密码学不够熟悉,但要知道这是否真的那么严重.

那么,是否所有ASP.NET开发人员都担心这种技术可以在几秒钟内拥有任何ASP.NET网站或者什么？

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

谢谢你的回答!

编辑:让我总结一下我得到的答复

所以,这基本上是一种"填充oracle"类型的攻击.@Sri提供了一个很好的解释,说明这种类型的攻击是什么意思.这是一个关于这个问题的令人震惊的视频!

关于此漏洞的严重性:是的,它确实很严重.它允许攻击者了解应用程序的机器密钥.因此,他可以做一些非常不需要的事情.

在应用程序的机器密钥的位置,攻击者可以解密身份验证cookie.
更糟糕的是,他可以使用任何用户的名称生成身份验证cookie.因此,他可以像网站上的任何人一样出现.应用程序无法区分您或为您自己生成身份验证cookie的黑客.
它还允许他解密(并生成)会话cookie,尽管这不像前一个那样危险.
不那么严重:他可以解密加密的ViewState页面.(如果您使用ViewState存储确信数据,则不应该这样做!)
非常意外:凭借对机器密钥的了解,攻击者可以从您的Web应用程序下载任意文件,即使是那些通常无法下载的文件!(包括Web.Config等)

以下是一些我没有解决问题的良好实践,但有助于提高Web应用程序的一般安全性.

现在,让我们关注这个问题.

解决方案

启用customErrors并创建一个错误页面,重定向所有错误.是的,甚至404s.(ScottGu说,区分404s和500s对于这次攻击至关重要.)另外,进入你的Application_Error或者Error.aspx放一些随机延迟的代码.(生成一个随机数,并使用Thread.Sleep长时间休眠.)这将使攻击者无法确定您的服务器上究竟发生了什么.
有些人建议切换回3DES.理论上,如果您不使用AES,则不会遇到AES实现中的安全漏洞.事实证明,根本不建议这样做.

其他一些想法