微软安全响应中心近日发布新安全预警， 提醒广大ASP.NET用户防范一处新安全漏洞。攻击者可利用存在于ASP.NET加密模块的一处新漏洞访问到包括web.config在内的任何文件。 此漏洞存在于ASP.NET所有已发布的版本中，其影响程度不容小视。途必科技研发中心深入研究ASP.NET新安全漏洞，并率先为客户提供解决方案。
有关该漏洞的详细信息, 请访问: http://www.microsoft.com/technet/security/advisory/2416728.mspx
首先我们来分析这次是如何对ASP.NET站点进行攻击的呢？方式有不少，例如攻击者可以为一个需要认证的请求发送自定义的cookie值，如果没有通过认证，则会得到一个转向登陆页面的302跳转。一个更为直观和通用的作法来自于PPOA论文的作者所提供的一段视频，其中使用了WebResources.axd?d=xyz进行探测工作。WebResource.axd有一个特点，便是会对错误的密文（即d=xyz中的xyz）产生500错误，而对正确的密文产生404错误，这便形成了足够的提示。
好，那么假设攻击者已经得到了站点的Machine Key，也就是网站所使用的密钥，那么它又能造成什么危害呢？
一些危害是很容易理解的，例如解密（或注入）ViewState，或是如视频里那样设置一个管理员的cookie。在ScottGu等文章中描述这个漏洞的危害时还提到，这个漏洞可以用来下载web.config等私密文件，这又是如何办到的呢？要知道web.config文件的下载是被IIS和ASP.NET所禁止的，它似乎和加密解密或是Machine Key无关。不过您是否意识到，在ASP.NET 3.5 SP1以后，我们可以利用ScriptManager来打包输出本地的脚本文件？例如：
有趣的是，在今年两月和六月有黑客提供了攻击CAPTCHA和攻击Apache MyFaces的视频，同时也提供了一个针对JSF的自动攻击工具，不过它们并没有形成微软对ASP.NET的漏洞那样强烈反应。
防止攻击
目前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产品的缘故。
此外还有一些做法也是可取的。例如：
>> 避免在ViewState和Cookie中存放敏感数据。
>> 不要过度依赖Machine Key。
>> 在认证cookie里保存的不只是用户名，而是外界无法得知的ID，或是同时保存checksum等额外的验证信息。
>> 为ScriptResource.axd写一个Wrapper，只让它输出扩展名为js的内容。
这些做法的目的是：即使攻击者得到了Machine Key，也无法对站点造成破坏。
总结
安全性漏洞总是不令人愉快的，但是在遇到这种状况的同时，我们也要努力得知问题的真实情况。在如今信息爆炸的时代，产生和获取一条没有多大价值甚至是错误的信息，可谓是非常容易的。排除干扰寻求真相，即便只是种态度和意愿，也是一名技术人员的基本素质。因此在这个问题上，途必科技研发中心提示客户不要有一下情绪：“微软的产品就是不安全”，“反正我不会被攻击”这样的态度。
专属顾问
