渗透测试步骤

(1)确定应用程序中存在的任何跨站点脚本漏洞,看是否可以利用这些漏洞截获其他用户的会话令牌(请参阅第12章了解相关内容)。

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

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

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

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

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

7.3.6 宽泛的cookie范围

cookie的工作机制可简单概括如下:服务器使用HTTP响应消息头Set-cookie发布一个cookie,然后浏览器在随后的请求中使用Cookie消息头向同一台服务器重新提交这个cookie。事实上,事情远比这复杂。

cookie机制允许服务器指定将每个cookie重新提交到哪个域和哪个URL路径。为完成这一任务,它在Set-cookie指令中使用domain和path属性。

1.cookie域限制

位于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属性,以改变这种默认行为。例如,假设位于foo.wahh-app.com的应用程序返回以下HTTP消息头:

img201

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

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

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

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

img202a

因为cookie被自动重新提交到这个范围内的每一个子域,当一名已经登录的用户浏览其他用户的博客时,他的会话令牌将与其请求一起提交。如果允许博客作者在他们自己的博客中插入任意JavaScript脚本(就像现在的许多博客应用程序那样),那么一个恶意博客作者就能够以和保存型跨站点脚本攻击一样的方式窃取其他用户的会话令牌(请参阅第12章了解相关内容)。

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

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

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

img202b

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

img202c

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

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

img002 与前面的博客应用程序一样,其他应用程序的功能可能会将提交给应用程序的cookie值泄露给第三方。

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

img001  注解  通常而言,基于域的cookie隔离并不像同源策略(请参阅第3章)那样严格。除了在处理主机名时讨论的问题外,浏览器还会在确定cookie范围时忽略协议和端口号。如果某个应用程序与另一个不可信的应用程序共享主机名,并依赖协议或端口号中的差异来隔离自身,那么,攻击者通过处理cookie即可轻而易举地破坏这种隔离。该应用程序发布的任何cookie都可被与它共享主机名的不可信应用程序访问。