ASP.NET的安全漏洞

三大问题

Moore先生在最近召开的CanSecWest会议上介绍了他的发现（你可以在digitaloffense.com上看到他的文章）。在介绍完他在ASP.NET平台上发现的三个安全问题后，Moore示范了如何利用它们来攻击系统。其中的某些攻击手段，特别是利用“cookie-less会话（session）”会让你觉得简单的不可思议。

Cookie-less会话漏洞

“cookie-less会话”利用了ASP.NET中cookie-less会话管理模式的一个漏洞，它包括了任何URL中的会话标识（id）。尤其是当新会话的id交给服务器时，新会话就创建了，而不是服务器负责创建这些会话。这个漏洞使得攻击者可以窃取会话并装扮成一个合法用户自由访问程序。

按照Moore的说法，攻击过程大致如下：

1、提交一个有效但是伪造的会话id，这个过程实现起来并不困难，因为会话id并没有加密处理。

2、把上述的会话id嵌入到一个URL中，并通过电子邮件或者其它手段发送到用户手中。

3、当用户点击这个URL并进入URL对应的页时，会话id仍保持有效，这时攻击者就有了被欺骗的用户的所用系统访问的权限。

不良配置控制带来的信息泄漏

Moore还发现一个潜在攻击者可以用来检查有问题的应用程序的结构甚至在某些情况下程序实际代码的方法。这个问题部分出于应用程序的开发者不良配置控制，部分归咎于错误的技术资料。

ASP.NET可以在应用程序出错时可以向用户显示出自定义错误信息。当调试应用程序时，常常关闭这个特性，这就造成服务器向客户返回堆栈轨迹（stack trace）以及调试信息（不仅仅是常见的“发生一个错误”消息）。如果自定义错误信息未被使能，调试信息仍会保留在正式发布的应用程序中（这是Visual Studio.NET默认设置），文家名和路径以及源代码环境中的任何错误都会返回给用户。

Moore说，这些信息嵌入在错误页的HTML内容中，所以你只有查看页面的源代码才可以看到它，但是这造成了一个潜在的危险问题。这些信息可能会给攻击者侦察你的应用程序帮了大忙，这些信息还可能帮助你的竞争对手对你的程序进行反向工程（破解）。

如果上面说得这些对你来说还不够的话，那么让我们看看ISAPI文件扩展名过滤器的情况吧，它用来保护特定类型的文件不被任意下载和浏览，不过它不会自动保护txt、csv和xml格式的文件不被身份通过验证的用户访问。如果你没有看出这里出现的问题，请参考微软操作规程建议中关于用xml文件来进行用户身份鉴定的部分，假定你把users.xml文件放到根目录下，这样任何一个有合法身份的用户都可以下载并查看该文件，这样他/她就会得到该应用程序所有用户的口令了。

Moore说新版的微软操作规程建议建议把该文件保存到一个受保护的目录下，这样这个门就关闭起来了。但是工程中剩余的文件（例如扩展名为sln和slo的文件）和其它可能引发问题的东西仍可能被访问到。他建议在应用程序发布之前删除这些文件，并建议开发者不要在根目录上存放任何文件以防被他人看到。

一个传统的缺陷

Moore还发现aspnet_state会话句柄类容易受到溢出性攻击，而攻击者可以通过溢出性攻击来执行任意的代码。这种缺陷是很普遍的，在普通应用程序中发现几十个也不希奇，所以，从表面上看来，Moore在ASP.NET中发现这个问题并没有什么好吃惊的。那到底是什么使得他感到吃惊（其实他感到的是极其的吃惊）呢？这就是.NET管理运行时的环境，因此它应该排除在应用程序中出现未受保护的内存的可能性，并确保这种攻击无效。

安全问题＝别人的事情？

Moore说开发者被微软公司发布的不准确信息所蒙蔽并对此一无所知，各种各样的技术文章的作者也应当为这些安全问题的出现受到一定的指责。他说，例如，他发现许多书籍、杂志和微软公司的文章都没有深入讨论如何验证用户输入的有效性，而这个方法正可以防止上面提到的溢出性缺陷的出现。

我们很容易倾向定性为上述事件是微软公司掩饰安全问题或者认为微软过于匆忙的将一个不安全的产品推向市场。然而，我认为开发者应该坚定这个信念：安全问题并不是“别人的事情”。我们倾向于把安全的责任推给网络工程师或者开发工具提供商，却单单忘了自己。我们还养成了依靠二手资料的坏习惯，二手资料常常不准确，在获取技术信息上远远不如我们自己挖掘第一手材料，例如文档。不相信我？那么出版印刷技术书籍是怎么成为一个价值数以百万美元的产业？

当然，在如此弱智的利用users.xml文件进行攻击的方法，微软技术文档中没有提到。这就体现了自学和常识的重要性了。这里的教训就是：任何技术都不是绝对安全的，我们也不应该这么指望——即使它贴着“Microsoft”的标签。

查看本文来源