5.4.1 水平权限提升

水平权限提升是利用一个授权漏洞,获得与应用中同等用户相同或者较少的权限(与我们将在5.4.2节中讨论的更危险的垂直提升至更高权限相反)。我们使用一个虚构的Web购物应用作为例子,来看看识别这样一个授权漏洞的过程。首先,我们将设置浏览器,这样你可以使用第1章中讨论过的任意HTTP分析工具查看和操纵Web应用的所有输入和输出。然后,我们导航到该网站,立即着手识别网站创建新账户的方式。这非常简单,因为“建立新账户”功能就在现有用户登录的位置上(这些应用通常很渴望注册新的购物者!),如图5-7所示。

图5-7 建立新账户功能通常就在应用登录屏幕上

和大部分实用的Web购物应用类似,这个应用使用询问各种类型个人信息的表单来完成账户创建。我们确保适当地填写所有信息(不!)。临近这一过程的结尾,我们看到了结束或者创建账户选项,但是我们没有马上点击它,而是转向HTTP分析工具并且清除任何请求,这样我们就有了一块干净的黑板。现在可以继续点击按钮结束账户创建,这时的屏幕如图5-8所示。

图5-8 成功的账户创建

使用我们的分析工具,仔细地以原始HTTP格式查看发送到服务器的请求。这是创建账户的实际POST操作:


POST /secure/MyAcctBilling.asp HTTP/1.1
Host: secure2.site.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 414
Cookie: 20214200UserName=foo%40foo%2Ecom; 20214200FirstName=Michael;
BIGipServerSecure2.TEAM.WebHosting=1852316332.20480.0000; LastURL=
http%3A%2F%2Fwww%2Esite%2Ecom; ASPSESSIONIDQAASCCQS=
GKEMINACKANKBNLFJAPKNLEM
stealth=1&RegType=1&UserID=&Salutation=Mr&FirstName=Michael&LastName=
Holmes&EmailAddress=foo@foo.com&Password1=testpassword&Password2=
testpassword&DayPhone1=678&DayPhone2=555&DayPhone3=555&AltPhone1=
&AltPhone2=&AltPhone3=&Address1=294+forest+break+lane&Address2=&City=
atlanta&State=GA&Country=United+States&PostalCode=30338&CCName=0&CCNum=
&CCExpMonth=0&CCExpYear=0000&update_billing_info=on&submit.x=
43&submit.y=13

下面是来自服务器的响应:


HTTP/1.x 302 Object moved
Set-Cookie: BIGipServerSecure2.TEAM.WebHosting=1852316332.20480.0000; path=/
Set-Cookie: UserID=2366239; path=/
Set-Cookie: ShopperID=193096346; path=/
Set-Cookie: 20214200UserName=foo@foo.com; path=/
Date: Wed, 12 Oct 2010 18:13:23 GMT
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
Location: https://secure2.site.com/secure/MyAcctBillingSuccess.asp?r=1
Content-Length: 185
Content-Type: text/html
Cache-Control: private

我们在本章前面已经说过,cookie通常包含用于识别会话的授权信息,所以我们留意一下这个响应中的Set-Cookie值。表5-7中总结了这些值。

表5-7 从我们的虚构Web购物应用中收集的cookie信息

注意,ShopperID和UserID看上去很有希望。这些cookie名相当明显地指出了与授权的关系,对应值为数字,这意味着每个数值都可能是简单操纵攻击(下一序列反复等)的对象。

现在我们的任务是领会这些cookie实际的使用方式,以及ShopperID和UserID令牌是否如我们所想。为此,我们必须重放这些cookie到应用中,同时针对那些误用之后可能导致权限提升的功能。在本章的前面我们已经讲过,Web授权中最常被误用的方面是账户管理界面,尤其是自助功能。按照这一想法,我们直奔Web应用中让用户查看和编辑自身账户信息的界面。使用Hewlett Packard的HTTP Editor(购买了他们的WebInspect产品就能够找到),我们分析了这个界面的底层HTTP,同时遍历了应用的图形化HTML界面,如图5-9所示。

使用这种自助功能,我们利用之前找到的仿冒授权cookie进行了一些重放测试。下面是它们从客户端重放到服务器时HTTP首部的样子:


Cookie: 20214200UserName=foo%40foo%2Ecom; 20214200FirstName=Michael;
BIGipServerSecure2.TEAM.WebHosting=1852316332.20480.0000; LastURL=
http%3A%2F%2Fwww%2Esite%2Ecom; ShopperID=193096346;
ASPSESSIONIDQAASCCQS=GKEMINACKANKBNLFJAPKNLEM; UserID=2366239

为了验证我们对ShopperID和UserID用于授权决策的猜测,现在开始单独删除每个cookie并且发回请求。删除UserID cookie时,服务器仍然响应图5-8中的账号注册页面。因此,这个cookie现在对我们的任务不重要。我们为每个cookie重复前面的步骤,直到最终删除一个cookie的响应是HTTP 302 redirect,这告诉我们删除的令牌对于验证是必需的。当我们删除ShopperID cookie时,最终得到下面的响应:


HTTP/1.1 302 Object moved
Date: Wed, 12 Oct 2010 18:36:06 GMT
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
Location: /secure/MyAcctLogin.asp?sid=
Content-Length: 149
Content-Type: text/html
Set-Cookie: ASPSESSIONIDQAASCCQS=OOEMINACOANKOLIIHMDAMFGF; path=/
Cache-control: private

这告诉我们ShopperID cookie最可能是应用授权令牌。

图5-9 使用Hewlett Packard的HTTP Editor分析虚构Web购物应用的账户编辑界面

注意  在这个网站上,我们实际上发现BIGipServer cookie也能导致失败的授权,但是因为我们知道BIG-IP是F5 Networks公司的一个Web负载平衡产品,所以不考虑它。但以后确实必须回放BIGip令牌,因为它对与此网站的通信是必需的。

这时,我们可以修改ShopperID cookie值并重放到服务器来测试其漏洞。因为我们刚刚创建了账户,将ShopperID数从193096346递减为193096345,看看能否访问在我们之前创建的账户。下面是修改之前的客户cookie首部:


Cookie: BIGipServerSecure2.TEAM.WebHosting=1852316332.20480.0000;
ShopperID=193096346;

下面是有新ShopperID值的首部:


Cookie: BIGipServerSecure2.TEAM.WebHosting=1852316332.20480.0000;
ShopperID=193096345;

我们发送第二个递减的值到服务器,检查是否返回相同的账户信息。成功!图5-10显示“Emily Sima”的账户数据。我们已经找出了一个水平权限提升漏洞,而且,攻击者现在可以枚举所有账户并且获得个人数据,甚至以任何用户的所有账户权限进行仿冒。

图5-10 成功!现在可以改变另一个账户的信息