我们注意到十分有趣的是，t可以从服务器返回到客户的 HTTP Date 标头中提取出来，与这个 cookie 第一次的设置一起。这意味着 TOKEN cookie 是完全可预测的。事实上，如果有人了解 cookie 所产生时的时间排列 T MILY: 'Andale Mono', 'Lucida Console', Monaco, fixed, monospace; MARGIN-BOTTOM: 0px; FONT-SIZE: 11px" class="displaycode"> 获取第一对 (id1， TOKEN1)。记录 t1 –
服务器时间(从 Date HTTP 标头开始)
等待ΔT 秒钟。获取第二对 (id22， TOKEN2)。
记录 t2–服务器时间从 Date HTTP 标头开始)。
如果 (id2 > id1 +1) 开始 //
我们在这里插入看一个受害者会话。
对于 (x= t1 ; x < t2+1000 ; x++) //
它只是ΔT+1000 迭代开始
尝试这对 (id1 +1, ( 31415821 * x + 1 ) mod 100000000) 终止
事实上，通过利用这样的事实在某些案例中改进这个算法是可能的，在有些操作系统上，最小单位的计数器并没有精确到毫秒的粒度，而是较粗糙的10毫秒的粒度。这可被用来减少更多的搜索空间。
上面所描述的攻击可以使攻击者来扮演一个受害者的角色，假定这样的受害者被分配到两个由站点 cookie 构成的样例攻击者之间。因为攻击者可以任意重复很多次这样的算法，这样攻击者就可能为客户获取这些 cookie ，以抽样这个站点(就是说，每分钟一个请求)为代价，此外，每次发现新客户时就有1060个请求。正如上面所暗示的，在更近的间隔(每次一秒)中抽样以及利用时钟最小单位粒度的问题是有可能的，在这样的案例中很可能达到每个新客户100个请求。
如果在网络拥挤时下载这个站点执行了一个客户的模拟尝试，那么额外的数百或者数千计的请求就会不被注意，至少不会立即被注意。
案例 2. 当 Random() 不是随机时
在这个例子中，我们处理一个仍旧流行的(然而有些过时的)应用程序引擎。这个引擎为每个新会话产生一个单独的 cookie (我们称它为ID)，包括三个强制性的区域(F1，F2，以及F3)以及一个可选择的(服务器配置从属)区域(F4，在句号之前)的多连环体。这些区域如下所示：
F1 = 6 字符串(A-Z0-9) – PRNG (Pseudo Random Number Generator) 数据，
用基础36附带领头的零来表示F2 = 3 字符串 (A-Z0-9) –
服务器时间(毫秒)，被 2000 除，
绝对值为 363 (=46656)， 用基础36附带领头的零来表示
F3 = 3字符串(A-Z0-9) – 会话在这两秒时间内计算，用基础36来表示 36
F4 = 不变的字符串(每个服务器)
正如您所看到的，F4 (如果它存在的话) 是常量，因此可以进行琐碎的预测。 F2 仅仅是这个服务器时间(以秒计算)除以2，模数为 46656，它是一个完全可预测性的，以及 F3 也不是特别不出名——它随着时间的推移在每两秒内连续地增长(通常从1开始)。
唯一有趣的区域是 F1。显然，它有足够的熵来确保这个系统的安全，因为它能够假定 366值(=231.0)。然而，第一眼看起来安全的其实在执行完整的分析时并不那么安全。在 Appendix A 中阐述了 F1是如何以及为什么可以被预测的，因为太长所以这里没有包含这部分呢内容。我们利用 F1所解决问题的事实是它使用了一个 PRNG (Pseudo Random Number Generator)，它本质上就是可预测的。因此了解几个 F1 的值从而全面预测这个 PRNG，也就是未来的(和过去的) F1值。
这就是这样一次攻击的概要：
准备工作：
获取三个 ID，在最短的时间间隔中是可能的。
摘取 PRNG 内部状态(正如 Appendix A 中所阐述的)。
截获周期获得一个 ID，以及记录服务器时间，t。
简单地说，假设t是偶数。
找出 PRNG 内部曾经用来产生这个 ID 的状态(正如 Appendix 中所描述的)
等到 ΔT 秒 (这里的ΔT 是偶数) 就获取一个新的 ID。
增加这个 PRNG，并记录旧的 ID 和产生这个 ID 之间的内部状态(正如 Appendix 中所描述的)。使内部值的列表为 L
//ΔT/2 迭代：
for (T=t; T
begin
for each internal PRNG state L, i.
begin
Try an ID cookie consisting of:
F1=generate from sample of PRNG at state i and i+1;
F2=T;
F3=1; // first session in this 2-second time period
F4=F4 of any ID above; //constant per server
end
end
正如您所看到的，它是可行的，尽管比较重要，可以预测一些 ID cookie 。对于可行性，它要求时间间隔(ΔT)很简短(并且与这台服务器的期望使用是相关的)，为了最小化 L 的长度(内部 PRNG 状态可能的列表)。如果这些间隔的确十分简短(不超过两秒)，并且是正确地计时，是可能的，要分辨一个新的会话是否在当前两秒钟时间内被插入，它可以使的这次攻击有更高的效率(只有当了解一个新的受害者会话的确已经创建后它才需要启用额外的请求)。它还应该被提到的是，避免丢失与这个网站的同步化 (PRNG 内部状态的同步化)，还需要保持不时地请求新 ID 的状态，从而加强这个攻击者对新值的 PRNG 内部状态。要记住的是，PRNG 很可能因为各种目的而是使用，这样就导致一个快速的去同步化 (要为它计算，就需要在一个封闭的时间间隔中重新使其同步化，比如每几分钟)。从另一方面看，通过检查应用在这个网站中其它的随机值，可能更清楚地看清 PRNG 的内部状态。这样可能会提供一个捷径，节省大量的计算能量。
值得注意的是，当这个攻击者与这个网站同步时，如果 IDs 可以频繁地被提取，就可能在发送一些请求的消耗中模拟任何客户端 (它取决于 PRNG 的使用)。
相关供应商的看法
Vendor 1 承认这些缺陷，并通知我们他的消费客户对于会与管理应该使用 SSL 资格认证。尽管这对于一些消费者来说可能是一个好消息 (但是明确地说并不是所有的消费者，因为移动到 SSL 以及 SSL 资格认证的确很重要 并且有时是不可能的)，这个产品的文献引导读者相信这个内嵌的会话管理是安全的(在他们给开发人员的文献中，他们称它为“客户安全标识”)。当然，这个供应商并没有把这个建议公开。
Vendor 2 承认了这些缺陷，然后给我们写信说：“会话 cookie 不是一个可代替的认证标识。一个连接中的会话 cookie 与一个随机鉴定标识或者鉴定登陆审核都是合理的机制。这在设计基于脚本的会话是可实现的——即使这里的会话标识今天是‘可信任的’。”因此，他们将这个责任交到开发人员的手中。
这两个供应商，都从技术上承认了这个问题，却将它解散成一个非安全性问题。也就是说，两个供应商假设他们的消费客户执行他们自己的会话安全标识，而不是依赖于这个供应商的标识，因此，他们声称他们的标识仅仅是用来(或者应该用来)更好区分不同的用户，而不是作为一个安全性评估。在这个文献中，我们没有找到任何关于将这个标识作为安全会话标识符的警告。进一步说， Vendor 1的文献使用了引导用户相信这个标识是安全的短语。然而实际上，绝大多数站点使用这个由供应商发布的标识作为安全会话的标识符，而忽略了它是有缺陷的事实。
从某种意义上说，应用程序开发人员又回到了这个一致性问题：开发人员不能相信这个内嵌的会话确认机制;因此，他们强调用他们最大的努力编写他们自己的机制，从而实现先前所提到的所有需求，避免密码系统的细微陷阱。
结论
病毒的闯入导致会话安全出现问题的事情发生频率非常高。Vendors 没有将它改正，也没有在乎它，或者将这个责任委托给开发人员。内部的开发是很容易出错的，并且需要对安全性有深入的理解。这篇文章提供了商业应用程序引擎中以及自身应用程序中不安全的真实案例。
这个结论很简单： Web 应用程序的世界应该包括三个部：
应用程序(它是在内部开发，表达了商业逻辑，以及这个公司或网站的新颖和独特之处)。
应用程序的环境(这个应用程序引擎和 Web 服务器，它使软件开发变得更容易，并且集中强调应用程序而不是组织结构)。
Web 应用程序安全构件，它负责这个软件的安全性，再次将开发人员(在某种程度上，也是这个应用程序引擎的开发人员!)从他们的应用程序安全执行的担忧中解救出来。
在这里所描述的案例中， 很显然 Web 应用程序防火墙应该加强这个应用程序引擎或者内部开发的应用程序对标识的产生(开发人员甚至不需要意识到这个问题)。他应该确保——通过使用加强的密码系统和安全测试机制——发送到应用程序的标识确实是真实的，而非虚假的。
文章来源于领测软件测试网 https://www.ltesting.net/
