鬼仔's Blog

作者：空虚浪子心

看了墨西哥同学（其实看不懂，刺帮忙翻译的）和刺的文章，不过我们主要关心该技术的利用。
sirdarckcat说，HTTP头的长度，在APACHE等web服务器是有一定的要求的，如果超出一定长度，会产生服务器错误。HTTP头里面，有cookie，有location，有host。。。如果我们可以控制其中一个（例如cookie），给用户植入大长度的cookie，就会出现用户访问该域下所有的请求，都带上大长度cookie，导致用户不管访问域名下的哪个文件，都会产生服务器错误，造成客户端无法访问。

HTTP头有很多字段，为什么非要提COOKIE插入大字段呢？从理论上讲，只要HTTP的头，大于某个值，就可以DDOS，但是问题是，只有COOKIE会跟着用户一直走。种入COOKIE后，无论访问哪里，都会发出去，但是其他字段，例如location等，虽然插入了，却只有一次请求带着，下次没有了。

那么，我们就有两个问题需要讨论。

1， 把HTTP header搞大，让用户访问时挂掉。

2， 把COOKIE搞大，让用户访问时挂掉。

如前文所说，http header中的其他字段，即使加入了大字段，导致apache错误，也只能让一次请求失败（或两次，因为有referer）。所以利用价值，当然就不如COOKIE中植入了。所以，我们把关注点放在COOKIE上。

下面统计有几种情况可以给用户种入cookie：

1， XSS，当某个域下出现了XSS漏洞，我们当然可以添加大cookie，例子见刺的文章http://hi.baidu.com/aullik5/blog/item/6947261e7eaeaac0a7866913.html。本文就不讲这个了，我喜欢把它叫做JS植入法。

2， 服务器上某个应用，接受用户的提交变量，再把用户提交的数据，加入到COOKIE中。我喜欢叫他server植入法。

要使用js植入法，就只能找XSS漏洞、或者能够影响“JS处理COOKIE”的那段数据的内容。

Server植入法的利用方式有两种，第一种是服务器接收了用户的输入，之后更改COOKIE的值为用户提交上来的值。这种方式是直接攻击应用，溢出http头，很暴力的撑大。只要一次提交，后面再也访问不了了，被apache拦截。第二种比较阴险，是一次一次的撑大，典型的应用就是购物车。一旦我们可以直接控制购物车放入cookie中的值，我们就可以一次一次的把它搞大，每次都可以访问，直到最后一次，就不能访问了。

请注意一点，墨西哥同学提出的是40X错误，是apache爆出来的，实际上，我们的应用也可能爆出来这个东西。当然，应用爆出来的漏洞，就不是40x错误了。

举个某的POC(影响太大，不敢乱点了，谨遵某巨牛法旨。。。)：

http://XXXXXXXXX.com/*****?*****=dagoogleweapondagoogleweapon
dagoogleweapondagoogleweapondagoogleweapondagoogleweapondagooglewea
pondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogl
eweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapond
agoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweap
ondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogle
weapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondag
oogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapon
dagoogleweapondagoogleweapondagoogleweapondagoogleweapondagooglewea
pondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogle
weapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondag
oogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapo
ndagoogleweapondagoogleweapondagoogleweapondagoogleweapondagooglew
eapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoog
leweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondago
ogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweaponda
googleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapo
ndagoogleweapondagoogleweapondagoogleweapondagoogleweapondagooglew
eapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondago
ogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapo
ndagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogl
eweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondag
oogleweapondagoogleweapondagoogleweapondagoogleweapondagooglewe
apondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoo
gleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapo
ndagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogle
weapondagoogleweapondagoogleweapondagoogleweapondagoogleweaponda
googleweapondagoogleweapondagoogleweapondagoogleweapondagooglewe
apondagoogleweapondagoogleweapondagoogleweapondagoogleweapondag
oogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweap
ondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoog
leweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapond
agoogleweapondagoogleweapondagoogleweapondagoogleweapondagooglew
eapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondag
oogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweap
ondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogl
eweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapond
agoogleweapondagoogleweapondagoogleweapondagoogleweapondagooglew
eapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondago
ogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapon
dagoogleweapondagoogleweapondagoogleweapondagoogleweapondagooglewe
apondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogl
eweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondago
ogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapond
agoogleweapondagoogleweapondagoogleweapondagoogleweapondagooglewe
apondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoo
gleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapo
ndagoogleweapondagoogleweapondagoogleweapondagoogleweapondagooglew
eapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondago
ogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapon
dagoogleweapondagoogleweapondagoogleweapondagoogleweapondagooglew
eapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondago
ogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapon
dagoogleweapondagoogleweapondagoogleweapondagoogleweapondagooglewe
apondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoo
gleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapond
agoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweap
ondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagsssssss
sssssssssssssssssssssssssssssssssssssssddddddddddddddddddddddddddddddddddddddddd

如果某竞争对手网站看你不顺眼，只要在自己的网页中，iframe一下这个地址，访问过竞争对少的用户，就登陆不了你的网站了。如下图，用户访问任何地方，只要是你域名下，全都是这个错误。

这个XX的例子其实是应用爆出来的错误，而不是apache爆出来的。也就是说，在这里APACHE其实是允许这么大字段的cookie的（没有到apache指定的长度），但是apache后面的应用（JAVA程序）却受不了这么大的字段。

那apache的400和应用的500到底有啥区别呢？

我们可以从DDOS的效果谈这个问题，用户被植入大字段的COOKIE后，每次访问，都会返回40X，其实是针对用户的，而对服务器来讲，一个40x，代价可能很低。

但是500就不一样了，JAVA本来就是虚拟机上的乌龟，再加上每次用户访问都扔个500过来，性能会受很大的影响，最后如果真的把服务器也XX了，那就溴大了。YY下，不需要XSS，不需要种马，一样DDOS，一旦规模的种植后，这个漏洞就不好补了。。。

Server植入法利用的漏洞，也是有一定的利用技巧的，首先猜测哪个服务器的应用可能操作cookie，之后手工测试，当找到漏洞点的时候，就开始加入大字段，之后递减。使用这种方式，就不需要再去找XSS了，因为通常情况下，XSS的功能是比较强大的，能挂马，而这个XSS点用于DDOS用户访问，就感觉浪费了。

ps：最后扩展下，在应用读取cookie出错的情况下，除了大字段出错，还有本来读取数字，提交的是字符，也可能出错。总之，只要能够引起应用出错的用户可控COOKIE，都可以攻击。