目录

会话令牌处理中的薄弱

1.3、令牌-会话映射易受攻击

简述：

过程：

1.4会话终止易受攻击

简述：

过程：

1.5客户端暴露在令牌劫持风险之中

简述：

过程：

1.6、宽泛的cookie范围

简述：

cookie域限制

过程：

cookie路径限制

WEB开发安全与防御策略

application/msword 4星 超过75%的资源 626KB

下载

会话令牌处理中的薄弱

1.3、令牌-会话映射易受攻击

简述：

1、由于应用程序在将生成和处理的会话令牌与令牌所属的用户会话之间进行对应的过程中存在薄弱环节、会话管理机制因此存在各种常见的漏洞

2、最简单的漏洞是允许给同一个用户账户同时分配几个有效的令牌。在几乎每一个应用程序中， 任何用户都没有正当理由在任何指定的时间拥有多个会话。当然， 用户可以终止一个处于活动状态的会话， 再开始一个新会话，例如， 关闭浏览器窗口或转换到另一台计算机上。但如果一名用户明显同时在使用两个不同的会话， 这通常表示出现了安全问题要么是因为用户将证书泄露给了第三方， 要么是攻击者通过其他某种途径获得了他的证书。无论发生哪一种情况， 都不应允许并行会话， 因为它允许用户持续执行任何非法操作， 同时允许攻击者使用截获的证书， 却不存在被检测出来的风险。

3、应用程序使用“静态” 令牌是一种相对较为特殊的缺陷。最初表现的功能和会话令牌一样， 但实际并非如此。在这些应用程序中， 每名用户都分配有一个令牌，并且用户每次登录， 都收到相同的令牌。无论用户是否已经登录并获得令牌， 应用程序都应将该令牌视为有效令牌。这种应用程序实际上是对会话的整体概念以及这样做有助于管理和控制应用程序访问存有误解。有些时候， 应用程序这样运作， 是为了执行设计上存在缺陷的＂记住密码" 功能， 并因此将静态令牌保存在一个持久性cookie中。令牌本身易于受到预测攻击， 致使这种漏洞造成更加严重的后果， 因为一次成功的攻击不仅能够攻破当前登录用户的会话， 如果时间允许，还能攻破所有注册用户的账户。

4、表明令牌和会话之间的对应关系存在基本的缺陷。根据用户名和一个随机成分构造的有意义令牌就是一个典型的示例。

user=toy;l1=634589097

根据样本值无法对l1进行预测，如果应用程序的会话处理逻辑存在缺陷， 可能攻击者只需向l1和user提交任何有效的值， 就可以在指定用户的权限下访问一个会话，这是一个访问控制漏洞，因为应用程序是根据用户在会话之外提交的数据做出的访问决定。产生这种漏洞是因为应用程序使用会话令牌表明请求者已经与应用程序建立某种有效的会话；处理会话的用户权限并不由会话控制，而是通过其他方式根据每个请求决定。在这种情况下， 请求者直接控制决定用户权限的方式。

---

过程：

1、用相同的用户账户从不同的浏览器进程或从不同的计算机两次登录应用程序。确定这两个会话是否都处于活动状态。如果是， 表示应用程序支持并行会话， 这样攻破其他用户证书的攻击者能够利用这些证书， 而不会有被检测出来的风险

2、用相同的用户账户从不同的浏览器进程或从不同的计算机几次登录和退出应用程序。确定应用程序在每次登录时是发布一个新会话令牌， 还是发布相同的令牌。如果每次发布相伺的令牌， 那么应用程序根本没有正确使用令牌

3、如果令牌明显包含某种结构和意义， 设法将标识用户身份的成分与无法辨别的成分区分开来。尝试修改所有与用户有关的令牌成分， 使其指向其他已知的应用程序用户， 确定修改后的令牌是否被应用程序接受， 以及是否能够让攻击者伪装成那名用户

1.4会话终止易受攻击

简述：

由于两方面的原因， 正确终止会话非常重要。尽可能缩短一个会话的寿命可降低攻击者截获、猜测或滥用有效会话令牌的可能性。如果用户不再需要现有会话，终止会话为用户提供一种使其失效的途径， 在进一步降低上述可能性的同时，在某种程度上确保共享计算环境中会话的安全。会话终止功能的主要缺陷大都与无法满足这两个关键目标有关。

一些应用程序并不实施有效的会话终止功能。会话一旦建立，它在收到最后请求后的许多天内也仍然有效，直到服务器及终将其清除。即使令牌存在也非常难以利用， 攻击者仍然能够截获最近访问应用程序的每一名用户的令牌。

一些应用程序并不提供有效的退出功能。

1、应用程序可能根本不执行退出功能。用户没有办法要求应用程序终止他们的会话。

2、退出功能可能实际上并不能帮助服务器终止会话。即使服务器从用户的浏览器中删除令牌（例如， 通过发布一个清空令牌的Set-Cookie指令）。如果用户继续提交这个令牌， 服务器仍然接受它

3、可能当用户单击“退出” 按钮时， 应用程序并不与服务器通信， 因此服务器不采取任何行动。相反， 应用程序执行一段客户端脚本清空用户的cookie， 在随后的请求中将用户返回到登录页面。访问这个cookie的攻击者就能使用会话，好像用户从未退出一样

---

过程：

1、不要掉入检查应用程序对客户端令牌执行的操作（如通过一个新的Set-Cookie指令、客户端脚本或者终止时间属性令cookie失效）的陷阱。在客户端浏览器内对令牌执行的任何操作并不能终止会话。调查服务器端是否执行会话终止操作

A、登录应用程序获得一个有效令牌；B、不使用这个令牌， 等待一段时间后， 使用这个令牌提交一个访问受保护页面（如“我的资料＂ 页面）的请求C、如果该页面正常显示， 表示令牌仍然处于活动状态；D、使用反复试验的方法确定会话终止超时时间， 或者一个令牌在最后一次使用它提交
请求几天后是否仍被使用。可配置Bp Intruder连续请求之间的时间间隔

2、确定是否存在退出功能， 用户是否能够使用这一功能。如果不能， 表示用户更易于受到攻击， 因为他们没有办法让应用程序终止会话

3、如果应用程序提供退出功能， 测试其效率。退出后， 尝试重新使用原有的令牌， 确定其是否仍然有效。如果令牌仍然有效， 那么即使用户已经退出，也依然易于受到会话劫持攻击。可以使用Bp测试此功能的效率， 具体操作：从代理服务器历史记录中选择一个依赖会话的最近请求， 在从应用程序中注销后将其发送给Bp Repeater重新发布该请求

1.5客户端暴露在令牌劫持风险之中

简述：

攻击者可以采用各种方法向应用程序的其他用户发动攻击， 试图截获或滥用他们的会话令牌

1、攻击者可通过跨站脚本攻击查询用户的cookie， 获得他们的会话令牌， 然后将其传送至自己控制的任意服务器。

2、攻击者可以使用其他针对用户的攻击， 以不同的方式劫持用户的会话。包括实施会话固定攻击， 即攻击者向一名用户发送一个已知的会话令牌， 等待他登录， 然后劫持他的会话；以及跨站请求伪造攻击， 其中攻击者从他控制的一个Web站点向应用程序提出一个专门设计的请求， 由于用户的浏览器会随同这个请求一起自动提交用户当前的cookie,攻击者因此会获得用户的cookie。

---

过程：

1、确定应用程序中存在的任何跨站脚本漏洞， 看是否可以利用这些漏洞截获其他用户的会话令牌

2、如果应用程序向未通过验证的用户发布令牌， 就会获得一个令牌并进行一次登录。如果应用程序在攻击者登录后并不发布一个新令牌， 就表示它易于受到会话固定攻击

3、即使应用程序并不向未通过验证的用户发布会话令牌， 仍然会通过登录获得一个令牌，然后返回登录页面。如果应用程序＂愿意” 返回这个页面， 即使攻击者已经通过验证， 那么也可以使用相同的令牌以另一名用户的身份提交另一次登录。如果应用程序在第二次登录后并不发布一个新令牌， 表示它易于受到会话固定攻击

4、确定应用程序会话令牌的格式。用一个格式有效的伪造值修改令牌， 然后尝试使用它登录。如果应用程序允许使用一个捏造的令牌建立一个通过验证的会话， 表示它易于受到会话固定攻击。

5、如果应用程序并不支持登录功能， 但处理敏感数据（如个人信息和支付细节）， 并在提交后显示这些信息（如在“确认订单” 页面上）， 那么使用前面的三种测试方法尝试访问显示敏感数据的页面。如果在匿名使用应用程序期间生成的令牌可用于获取用户的敏感信息， 那么应用程序就易于遭受会话固定攻击。

6、如果应用程序完全依靠HTTP cookie传送送会话令牌， 它很可能容易受到跨站请求伪造(CSRF)攻击。首先登录应用程序，再从另一个应用程序的页面向应用程序提出一个请求， 确认它是否会提交用户的令牌。（必须从与登录目标应用程序相同的浏览器进程窗口提交令牌。）设法确定所有参数可由攻击者提前决定的应用程序敏感功能， 利用这种缺陷在目标用户的权限下执行未授权操作

1.6、宽泛的cookie范围

简述：

1、cookie的工作机制可简单概括如下：服务器使用HTTP响应消息头Set-cookie发布一个cookie， 然后浏览器在随后的请求中使用Cookie悄息头向同一台服务器重新提交这个cookie

cookie机制允许服务器指定将每个cookie重新提交到哪个域和哪个URL路径。通过在Setcookie指令中使用domain和path属性

---

cookie域限制

1、位于foo.wahh-app.com的应用程序建立一个cookie后， 浏览器会默认在随后的所有请求中将cookie比重新提交到foo.wahh-app. com及任何子域（如admin.foo. wahh-app.com)中。它不会将cookie提交给其他任何域， 包括父域wahh-app.com和父域的其他任何子域， 如bar.wahh-app.com。

服务器可以在Set-cookie指令中插人一个domain属性，以改变这种默认行为。例如， 假设位于fool.wahh-appicom的的应用程序返回以下HTTP头：

Set-cookie:sessionId=……;domain=wahh-app.com; 

浏览器会将这个cookie重新提交给wahh-app.com的所有子域， 包括bar.wahh-app.com

注：服务器不能使用这个属性随意指定域。首先， 指定的域要么必烦是应用程序在其上运行的域， 要么是它的父域（或为直接父域，或有一定间隔）。其次， 指定的域不能为.com或.co.uk之类的顶级域， 因为这样做会允许恶意服务器在其他任何域上建立任意cookie。如果股务器违反以上任何一条规定，浏览器将完全忽略Set-cookie指令

2、如果应用程序将cookie范围设定得过于宽泛， 也可能会使应用程序出现各种安全漏洞。

以一个允许用户注册、登录、写文章、阅读的博客应用程序为例。它的主应用程序位于域wahh-blogs.com上， 当用户登录这个应用程序时， 他会从一个以这个域为范围的cookie中收到会话令牌。每名用户都可以创建自己的博客， 通过以用户名为前缀的一个新的子域进行访问（如hero.wahh-blogs.com）

因为cookie被自动重新提交到这个范围内的每一个子域， 当一名已经登录的用户浏览其他用户的博客时， 他的会话令牌将与其请求一起提交。如果允许博客作者在他们自己的博客中插入任意JavaScrip脚本， 那么一个恶意博客作者就能够保存型跨站脚本攻击一样的方式窃取其他用户的会话令牌

因为用户创作的博客是处理验证和会话管理的主应用程序的子域。HTTP cookie并没有能力帮助应用程序防止主域发布的cookie被重新提交给它的子域。

解决：主应用程序使用一个不同的域名（如www.wahh-blogs.com)，并以这个完全合格的域名为它的会话令牌cookie的域范围。如果登录用户浏览其他用户的博客，会话cookie就不会被提交。

3、如果一个应用程序明确以一个父域作为它的cookie攻范围， 就会出现这种漏洞的另一个版本。例如， 假设一个安全性至关重要的应用程序位于域sensitiveapp.wahh-organization.com上， 当它建立cookie时， 它自由设置的域范围如下

Set-cookie:sessionId=……;domain=wahh-organization.com; 

这样做造成的后果是当用户访问wahh-organization.com使用的每一个子域时， 机密应用程序的会话令牌cookie都将被提交。这些子域包括

www.wahh-organization.com

testapp.wahh-organization.com

虽然这些应用程序可能全都属于拥有机密应用程序的同一组织， 但由于以下原因， 不应将敏感应用程序的cookie提交给其他应用程序。

A、负责其他应用程序的人员与负责机密应用程序的人员的信任级别不同

B、与前面的博客应用程序一样， 其他应用程序的功能可能会将提交给应用程序的oookie值泄漏给第三方

C、其他应用程序可能并不像机密应用程序那样遵循同样严格的安全标准， 或者接受全面的安全测试（因为它们不重要、不处理敏感数据， 或仅为测试目的）。应用程序中存在的许多漏洞（例如跨站脚本漏洞）可能不会影响它们的安全状况， 但外部攻击者却可以利用一个不安全的应用程序截获由机密应用程序创建的会话令牌。

---

过程：

审查应用程序发布的所有cookie， 检查用于控制oookie范围的任何domain属性

1、如果应用程序将cookie范围明确放宽到父域， 则该应用程序可能易于受到通过其他Web应用程序实施的攻击

2、如果应用程序将它的cookie范围设置为自己的域名（或者并未指定domain属性），则通过它的子域仍然可以访问其中的应用程序或功能

确定将收到应用程序发布的cookie的所有可能的域名。如果通过这些域名可以访问任何其他Web应用程序或功能， 确定是否可以利用它们获得目标应用程序的用户发布的cookie

---

cookie路径限制

1、位于/apps/secure/foo-app/index. jsp的应用程序建立一个cookie后， 浏览器会默认在随后的所有请求中将cookie重新提交到路径/apps/secure/foo-app/及任何子目录。它不会将cookie提交到父目录或服务器上的其他任何目录路径

2、与cookie范围域限制一样， 服务器可以在Set-cookie指令中插入一个path属性， 改变这种默认行为。例如， 如果应用程序返回以下HTTP消息头

Set-cookie:sessionId=……;path=/apps/;

那么浏览器会将这个cookie重新返回到/apps/路径的所有子目录中 

3、相比于基于域的cookie范围， 这种基于路径的限制比同游策略更加严格。如果将其作为一种安全机制， 用于防范同一域中的不可信应用程序， 则这种防御机制几乎完全无效。在某个路径上运行的客户端代码能够打开指向同一域上不同路径的窗口或ifram，并能够读取或写入该窗口， 而不受任何限制。因此，获取范围为同一域上的其他路径的cookie并不困难