这篇文章阐述了为什么会话管理和会话管理安全性都是复杂的工作，这就是为什么它们经常会留给商业产品来处理。这篇文章描述这两个商业应用程序引擎的语言符号是怎样产生的。作者分析了每个机制的能力，阐述了它的弱势，还论证了这样的弱势怎样才能被利用，从而执行模拟和私人违规攻击。他还讨论了攻击性的可行性。最后，他提出一种将安全性从功能中分开的会话管理的方法，并且后者由应用程序引擎实施，但是前者是由一个专门的应用程序安全产品所提供的。

　　cookie 篡改风险的特征

　　cookie 篡改 (cookie poisoning) 是一项主要以获取模拟和隐私权泄密著称的技术，通过维护客户(或终端用户)身份的会话信息操纵来实现的。通过打造这些 cookie ，一个黑客可以模拟一个有效的客户，因此获取详细信息并执行代表病毒的行为。这种打造的能力，像会话 cookie (或者更通俗地说，会话标识)源自于这些标识不是以安全的方式产生的事实。

　　内部会话维护的无休止工作

　　在 Web 应用程序程序设计中，会话管理是复杂且笨拙的。程序设计者会担心会话管理的许多方面，它能够将他/她从主要目标中的注意力分散：执行这个使此网站唯一且有用的商业逻辑。

　　具体问题：

　　会话的创建和识别：您如何能够确定何时的确需要一个新的会话，而且它确实已经创建了?程序设计者必须鉴定有一个客户确实需要一个会话，并创建这个会话以及为这个客户分配一个会话。

　　并发问题：当两个客户同时访问这个网站时，每个都需要一个新的会话，就有必要确保这个会话创建过程仍然能够正确地运行。

　　会话的终止和暂停：是什么导致一个会话终止的呢?这些终止的会话资源是如何被重新循环使用的呢?当正在进行终止过程时客户访问这个网站，又会发生什么情况呢?当客户访问带有就的会话的网站时会发生什么情况呢?

　　会话数据存储，多个服务器，失败。会话的数据储存在什么地方呢?磁盘上?随机存储器上?会有什么样的高性能惩罚?如果一个客户访问第一个服务器(并建立一个会话跟它一起)，然后被(负载均衡服务器)导向到第二个服务器，那么在一个多服务器站点将会发生什么?如果原始服务器坏掉，对这个客户会话数据将会有什么样影响?

　　安明智，下面这些点非常重要，值得思考：

　　一个客户要想预测另一个客户所接受的，或者正在接受的，或者即将接受的标识，几乎是不可能的。这很显然是一个必须防止的模拟攻击，因此也会违背隐私权。

　　此外，理想的情况是，当访问一个站点时，客户不能够预测下一个他们即将获取的标识。这对当它来回漫游(不受阻碍)时最小化窃取标识的损坏很有用处，而且在它储存在客户的计算机上也很有用。

　　任何标识都应该有一个合理的期限——可再次将它被窃取的损坏程度降到最低。

　　正如您所说，要实现所有的请求并不十分容易，尤其是当这个会话机制发展成无线自组织网时。就会有更复杂的安全需求来明确开发人员，尤其是对安全并不十分熟悉的人员，他们更容易遗忘。

　　在标识中有很多安全不足的例子。这些在 MIT Laboratory for Computer Science 的著作中有很好的证明(请看Dos and Don'ts of Client Authentication on the Web由 Kevin Fu， Emil Sit， Kendra Smith， 以及 Nick Feamster 合著)。这样，我们就清楚生产一个良好的会话管理解决方案是相当困难的，更不用说一个安全的会话管理解决方案了。这就是为什么应用服务器如此这样受人欢迎的原因之一。

　　应用服务器和引擎：解决方案和问题

　　一个 Application Server(或者 Application Engine)就是一个软件程序，是用来使这个应用程序开发者的工作更轻松。它通常会为程序开发者提供编写 HTML 网页的便利，而且这些网页中带有服务器嵌入的指导，指示这个服务器来执行各种任务。大多数应用服务器会为程序开发者提供自动管理会话的环境，将程序开发人员从上面板块中所有提到的担忧中解救出来。

　　应用服务器的案例：

　　Microsoft® ASP .NET， 是在 IIS 顶端进行运行的

　　Macromedia

　　ColdFusion

　　Apache Tomcat

　　Apache JServ

　　PHP

　　BEA WebLogic

　　IBM ® WebSphere® Application Server。

　　Security Space Web 网站的 Internet Cookie Report 网页通过将这些 cookie 的名称和发行它们的服务器联合起来，从而提供了一些频率分析。当然，这样说是不全面的，因为一些服务器和站点以参数的形式而不是 cookie 的形式来使用标识的。

　　应用程序引擎的上面反应了这样一个事实：他们完全将程序开发者从会话管理的担忧中释放出来。会话管理功能的各个方面，通常以更好的方式来管理，而并非内部程序员所能达到的。

　　应用程序引擎的下面反应了这样的事实：他们看起来是把程序员从标识安全性问题的担忧中释放出来。然而我们可以从损害的事实显示中看到，远不是这样的。事实上，一些十分受欢迎的应用程序殷勤根本就不提供安全标识。因此，程序员对安全性就有错误的意识。

　　我的合作伙伴和我检测到这些标识是由两个十分受欢迎的应用服务器所产生的。在这两个案例中，我们曾经证明这个标识并不是像它看起来那样的随意，它只是可能(在一个案例中，比较简单)会预测下一个会话(是不同客户的会话)标识的值。

　　案例 1. 打败一个基于时间的标识

　　这次攻击的目标是一个非常受欢迎的商业应用程序引擎。这个产品利用两个 cookie 来鉴定一个会话。由两个 cookie 形成的这对来鉴定一个会话。第一个 cookie 仅仅是一个计算器，每次有新的会话时就会增加。它大概能确保不可能有两对是相同的。第二个 cookie 是标识 cookie ，显然是通过“不可预知”来确保这对的安全。假设可以很轻松地预测第一个 cookie ，那么我们这里所关注的第一个 cookie ，就会被标识为TOKEN。

　　第一眼看到的时候，TOKEN 看起来是一个随机的八进制数字的序列。这里的熵是108 = 226.57，它可能是经过充分的考虑过，尝试如此多的请求(一亿次)次数是可行的，而不是一个没有控制警告和人们注意的网站。但是靠近看就会发现，事实上， TOKEN 符合以下的方程式：

我们用t表示 GMT 时间，按秒计算，因为 01/01/1970 00:00，与这个应用服务器上的设置一样。 我们用m表示这个应用服务器上最小单位毫秒。 那么： TOKEN= ( 31415821 * (t+m) + 1 ) mod 100000000

　

原文转自：http://www.ltesting.net