关于重复发包的防护与绕过

◆0.前言



目前由重复发包造成的问题主要有撞库，爆破等。而随着泄漏密码的越来越多，这一类问题造成的影响也越来越严重，随之大部分网站都做了对重复发包的防护。但是也有部分防护不完善，可以进行绕过。

◆1.基于IP的防护



许多网站为了防止重复发包这一问题，限制了每个ip的尝试次数，如果失败n次之后这个ip就暂时限制使用这一功能。

大部分php网站的获取ip都与$_SERVER[‘HTTP_X_FORWARD_FRO’]和$_SERVER[‘HTTP_CLIENT_IP’]有关(只会点php....)。看到这两个变量，大家都会想到http头的X-Forward-For和client_ip。由此可见，我们可以利用在http头修改这两个参数来进行绕过。

http://zone.wooyun.org/content/12716

◆2.基于token的防护

[*]token在cookie中
如果token基于cookie，由于cookie用户可控，所以这样的防护是没有意义的。

[*]token在session中

token在session中也分为两种情况。

一种token不修改的，也就是你每次提交的数据之后token不会改变，这样的话就没有防护能力。

另外一种是提交一次，token刷新一次，大概代码如下。

#!php
if($_SESSION['token']==$_POST['token']){ refreshToken(); if(isUser($_POST['username'],$_POST['password'])){ echo '登录成功'; }else{ echo '帐号或密码错误'; }
}else{ echo 'token错误';
}

这样的话，我们就不能直接进行重复发包了。不过由于token需要进行post提交，所以可以匹配出来网页form中的token，然后再进行组合发包。

◆3 基于验证码的防护



1 验证码存在cookie中

有一部分网站把验证码的值写在cookie中。只要输入一次正确的验证码，然后抓包进行爆破就行了。

例如 ESPCMS cookie中的ecisp_home_seccode

2 验证码存在session中

部分程序员在用验证码的时候，验证码判断完成之后不就行刷新。

大概代码如下:

#!php
if($_SESSION['seccode']==$_POST['seccode']){ if(isUser($_POST['username'],$_POST['password'])){ echo '登录成功'; }else{ echo '帐号或密码错误'; }
}esle{ echo '验证码错误';
}

这样的话，我们只要填写一次正确的验证码进行抓包，然后就可以直接重复发包了。

另外，大部分$_SESSION['seccode']都是由产生验证码的页面来进行赋值的，但是有的程序员不对$_SESSION['sescode']的值进行为空判断。

这样的话，我们可以这样绕过。

cookies清空，打开burp，然后打开登录页面，随后把获取验证码的请求直接drop掉，这样的话我们的$_SESSION['seccode']就是空了。然后抓包直接进行爆破。

http://wooyun.org/bugs/wooyun-2014-080424

3 验证码可以直接识别

这种情况就不多说了，乌云就是例子。

http://zone.wooyun.org/content/11826

4 验证码设计缺陷

验证码设计存在缺陷，可以通过某种条件产生一个特定的值。

http://wooyun.org/bugs/wooyun-2014-080211

◆4.基于可预测值防护



举例几种常见的情况

[*]通过回答指定的问题，来进行验证。常见的有网站域名的，网站标题等等。由于随机性太弱，所以我们可以设定其为其实一个问题的答案，然后进行爆破就行了。还有更直接的，直接在页面中这样输出 我们网站的域名是(答案为xxx.com)，这样的话就类似于2.2的绕过方法。

[*]1+1 3+1之类可预测结果范围的情况。

[*]有的网站会让你写出图形中某一特征的数值或者字母。这样的话变相的降低了验证码的可随机性。例如验证码为sx4g中的数字。数字一共只有10个，我们只要设定为其中一个为固定值进行测试。
这一问题主要造成的原因是因为值或者值的范围可预测，我们就可以设定一个固定的值作为答案，然后进行测试。