0x00.前言
目前由重复发包造成的问题主要有撞库，爆破等。而随着泄漏密码的越来越多，这一类问题造成的影响也越来越严重，随之大部分网站都做了对重复发包的防护。但是也有部分防护不完善，可以进行绕过。
0x01.基于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
0x02.基于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，然后再进行组合发包。
0x03 基于验证码的防护
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
0x04.基于可预测值防护
举例几种常见的情况
-
通过回答指定的问题，来进行验证。常见的有网站域名的，网站标题等等。由于随机性太弱，所以我们可以设定其为其实一个问题的答案，然后进行爆破就行了。还有更直接的，直接在页面中这样输出 我们网站的域名是(答案为xxx.com)，这样的话就类似于2.2的绕过方法。
-
1+1 3+1之类可预测结果范围的情况。
-
有的网站会让你写出图形中某一特征的数值或者字母。这样的话变相的降低了验证码的可随机性。例如验证码为sx4g中的数字。数字一共只有10个，我们只要设定为其中一个为固定值进行测试。
这一问题主要造成的原因是因为值或者值的范围可预测，我们就可以设定一个固定的值作为答案，然后进行测试。
云悉指纹