来源：自学PHP网 时间：2015-04-17 11:59 作者： 阅读:次
[导读] cookie 篡改风险的特征cookie 篡改 (cookie poisoning) 是一项主要以获取模拟和隐私权泄密著称的技术，通过维护客户（或终端用户）身份的会话信息操纵来实现的。通过打造这些 cookie ，一个...
|
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
我们注意到十分有趣的是，t可以从服务器返回到客户的 HTTP Date 标头中提取出来，与这个 cookie 第一次的设置一起。这意味着 TOKEN cookie 是完全可预测的。事实上，如果有人了解 cookie 所产生时的时间排列 T </- t < T+ΔT (按秒) ，他就可以推断出 TOKEN 有一个ΔT+1000 值，而不是一些值的简短列表。对服务器测试几千个以上的值可能要花几分钟，在这段时间受害者就可能仍然活跃。这就是一次攻击算法的大概要点：
获取第一对 (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<t+ΔT; T+=2)
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的文献使用了引导用户相信这个标识是安全的短语。然而实际上，绝大多数站点使用这个由供应商发布的标识作为安全会话的标识符，而忽略了它是有缺陷的事实。 www.2cto.com
从某种意义上说，应用程序开发人员又回到了这个一致性问题：开发人员不能相信这个内嵌的会话确认机制；因此，他们强调用他们最大的努力编写他们自己的机制，从而实现先前所提到的所有需求，避免密码系统的细微陷阱。
结论
病毒的闯入导致会话安全出现问题的事情发生频率非常高。Vendors 没有将它改正，也没有在乎它，或者将这个责任委托给开发人员。内部的开发是很容易出错的，并且需要对安全性有深入的理解。这篇文章提供了商业应用程序引擎中以及自身应用程序中不安全的真实案例。
这个结论很简单： Web 应用程序的世界应该包括三个部：
• 应用程序（它是在内部开发，表达了商业逻辑，以及这个公司或网站的新颖和独特之处）。
• 应用程序的环境（这个应用程序引擎和 Web 服务器，它使软件开发变得更容易，并且集中强调应用程序而不是组织结构）。
• Web 应用程序安全构件，它负责这个软件的安全性，再次将开发人员（在某种程度上，也是这个应用程序引擎的开发人员！）从他们的应用程序安全执行的担忧中解救出来。
在这里所描述的案例中， 很显然 Web 应用程序防火墙应该加强这个应用程序引擎或者内部开发的应用程序对标识的产生（开发人员甚至不需要意识到这个问题）。他应该确保——通过使用加强的密码系统和安全测试机制——发送到应用程序的标识确实是真实的，而非虚假的。
|
自学PHP网专注网站建设学习,PHP程序学习,平面设计学习，以及操作系统学习
京ICP备14009008号-1@版权所有www.zixuephp.com
网站声明：本站所有视频，教程都由网友上传，站长收集和分享给大家学习使用，如由牵扯版权问题请联系站长邮箱904561283@qq.com
