现在的位置: 首页 > IT运维 > 正文

怎样防止ASP.NET的Padding Oracle Attack

2010年09月26日 IT运维 ⁄ 共 829字 暂无评论 ⁄ 被围观 1,254+

目前ScottGu给出了多个workaround,归根结底便是消除“Oracle”,也就是提示信息。例如他强调要为404和500错误提供完全相同的反馈——不止是输出的错误页面,也包括所有的头信息(如Server Time等自然除外),这种做法会让攻击者无法得到提示信息,自然也就无法解密了。此外,ScottGu的一些代码同时让错误页面Sleep一小段时间,这也是种常用的混淆手段,让攻击者无法从响应时间长短上来了解这个请求“性质”如何。

从上面的分析中我们可以知道,这种统一错误信息的作法似乎是针对WebResource.axd和ScriptResource.axd的。由于我们知道了攻击的手段,便也可以采取其他作法。例如对于不需要这两个Handler的站点,就把它们从ASP.NET或IIS里直接摘除吧。还有,如果在日志中发现太多CryptographicException异常,便要关注站点是否遭受的攻击。

但是,Padding Oracle Attack的危害之处在于它所需要的信息实在太少,攻击者只需分辨两种状态便可以进行攻击,即便WebResource.axd的攻击被您防止了,那么之前提到的用户认证所带来的302跳转又如何?对于我们独立编写的应用程序来说,要绕开这个问题可以使用各种技巧。但对于微软来说可能就不容易了,因为 ASP.NET作为一个框架,它提供的是一种统一的,普适的机制,这也是为什么这个漏洞会影响几乎所有微软ASP.NET产品的缘故。

此外还有一些做法也是可取的。例如:

  1. * 避免在ViewState和Cookie中存放敏感数据。
  2. * 不要过度依赖Machine Key。
  3. * 在认证cookie里保存的不只是用户名,而是外界无法得知的ID,或是同时保存checksum等额外的验证信息。
  4. * 为ScriptResource.axd写一个Wrapper,只让它输出扩展名为js的内容。

这些做法的目的是:即使攻击者得到了Machine Key,也无法对站点造成破坏。

给我留言

您必须 [ 登录 ] 才能发表留言!

×
#