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的防护


  1. token在cookie中
    如果token基于cookie,由于cookie用户可控,所以这样的防护是没有意义的。

  2. 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.基于可预测值防护


举例几种常见的情况

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

  2. 1+1 3+1之类可预测结果范围的情况。

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