三大问题
Moore先生在最近召开的CanSecWest会议上介绍了他的发现（你可以在digitaloffensecom上看到他的文章）在介绍完他在ASPNET平台上发现的三个安全问题后Moore示范了如何利用它们来攻击系统其中的某些攻击手段特别是利用cookieless会话（session）会让你觉得简单的不可思议
Cookieless会话漏洞
cookieless会话利用了ASPNET中cookieless会话管理模式的一个漏洞它包括了任何URL中的会话标识（id）尤其是当新会话的id交给服务器时新会话就创建了而不是服务器负责创建这些会话这个漏洞使得攻击者可以窃取会话并装扮成一个合法用户自由访问程序
按照Moore的说法攻击过程大致如下提交一个有效但是伪造的会话id这个过程实现起来并不困难因为会话id并没有加密处理
把上述的会话id嵌入到一个URL中并通过电子邮件或者其它手段发送到用户手中
当用户点击这个URL并进入URL对应的页时会话id仍保持有效这时攻击者就有了被欺骗的用户的所用系统访问的权限
不良配置控制带来的信息洩漏Moore还发现一个潜在攻击者可以用来检查有问题的应用程序的结构甚至在某些情况下程序实际代码的方法这个问题部分出于应用程序的开发者不良配置控制部分归咎于错误的技术资料
ASPNET可以在应用程序出错时可以向用户显示出自定义错误信息当调试应用程序时常常关闭这个特性这就造成服务器向客户返回堆栈轨迹（stack trace）以及调试信息（不仅仅是常见的发生一个错误消息）如果自定义错误信息未被使能调试信息仍会保留在正式发布的应用程序中（这是Visual StudioNET默认设置）文家名和路径以及源代码环境中的任何错误都会返回给用户
Moore说这些信息嵌入在错误页的HTML内容中所以你只有查看页面的源代码才可以看到它但是这造成了一个潜在的危险问题这些信息可能会给攻击者侦察你的应用程序帮了大忙这些信息还可能帮助你的竞争对手对你的程序进行反向工程（破解）
如果上面说得这些对你来说还不够的话那么让我们看看ISAPI文件扩展名过滤器的情况吧它用来保护特定类型的文件不被任意下载和浏览不过它不会自动保护txtcsv和xml格式的文件不被身份通过验证的用户访问如果你没有看出这里出现的问题请参考微软操作规程建议中关于用xml文件来进行用户身份鑒定的部分假定你把usersxml文件放到根目录下这样任何一个有合法身份的用户都可以下载并查看该文件这样他/她就会得到该应用程序所有用户的口令了
Moore说新版的微软操作规程建议建议把该文件保存到一个受保护的目录下这样这个门就关闭起来了但是工程中剩余的文件（例如扩展名为sln和slo的文件）和其它可能引发问题的东西仍可能被访问到他建议在应用程序发布之前删除这些文件并建议开发者不要在根目录上存放任何文件以防被他人看到
一个传统的缺陷
Moore还发现aspnet_state会话句柄类容易受到溢出性攻击而攻击者可以通过溢出性攻击来执行任意的代码这种缺陷是很普遍的在普通应用程序中发现几十个也不希奇所以从表面上看来Moore在ASPNET中发现这个问题并没有什么好吃惊的那到底是什么使得他感到吃惊（其实他感到的是极其的吃惊）呢？这就是NET管理运行时的环境因此它应该排除在应用程序中出现未受保护的内存的可能性并确保这种攻击无效
安全问题＝别人的事情？Moore说开发者被微软公司发布的不准确信息所蒙蔽并对此一无所知各种各样的技术文章的作者也应当为这些安全问题的出现受到一定的指责他说例如他发现许多书籍杂志和微软公司的文章都没有深入讨论如何验证用户输入的有效性而这个方法正可以防止上面提到的溢出性缺陷的出现
我们很容易倾向定性为上述事件是微软公司掩饰安全问题或者认为微软过于匆忙的将一个不安全的产品推向市场然而我认为开发者应该坚定这个信念安全问题并不是别人的事情我们倾向于把安全的责任推给网络工程师或者开发工具提供商却单单忘了自己我们还养成了依靠二手资料的坏习惯二手资料常常不准确在获取技术信息上远远不如我们自己挖掘第一手材料例如文档不相信我？那么出版印刷技术书籍是怎么成为一个价值数以百万美元的产业？
当然在如此弱智的利用usersxml文件进行攻击的方法微软技术文档中没有提到这就体现了自学和常识的重要性了这里的教训就是任何技术都不是绝对安全的我们也不应该这么指望——即使它贴着Microsoft的标签
