02BWAPP通关指北——失效的身份认证和会话管理篇

这个是bwapp教程的第二篇（共十篇，对应owasp top 10 2013），其实十篇的教程早在几个月前都写完了，但是现在回头看看，理解和当时又不太一样，所以这些教程想慢慢发，加深一下自己对于web安全的认识。

作者：古月蓝旻

Broken Auth. - CAPTCHA Bypassing--low

验证码绕过，非常经典的一道题，还记得当年在宫司机的hackinglab里的验证码绕过的题目里也有一道与之非常相似的题目

所谓的验证码绕过主要是指本题的验证码失去了原本的作用，验证码本来主要用于防止暴力破解，在一次错误登录以后，验证码应该也要相应进行变化验证下一次登录，但是本题的验证码并未起到相应的效果，事实上它只要一次正确以后，后续的登录仍可使用该验证码，导致了验证码的失效，我们来看一下实际的操作

首先用户名密码处随便输入，在验证码处输入一次正确的验证码（注意大小写区分）

然后将密码字段添加爆破标记

在payload选项处填写一些随机密码，并将正确密码加入其中，开始爆破

根据返回包的长度差异可以看出其中bug对应的响应包长度有区别，此时查看可以发现显示为“Sucessful login!”，其它密码的的响应包显示为“Invalid credentials! Did you forgot your password?”

说明验证码根本就没有起到相应的效果

为啥会这样？

其实和hackinglab 脚本关的Q7原因是一样的

验证码发布的流程
1. 显示表单
2. 显示验证码（调用生成验证码的程序），将验证码加密后放进 session 或者 cookie
3. 用户提交表单
4. 核对验证码无误、数据合法后写入数据库完成
用户如果再发布一条，正常情况下，会再次访问表单页面，验证码图片被动更新， session 和 
cookie 也就跟着变了。
但是灌水机操作不一定非要使用表单页面，它可以直接模拟 post 向服务端程序发送数据，这样验证码
程序没有被调用，当然 session 和 cookie 存储的加密验证码就是上次的值，也就没有更新，
这样以后无限次的通过post直接发送的数据，而不考虑验证码，验证码形同虚设！
所以，在核对验证码后先将 session 和 cookie 的值清空，然后做数据合法性判断，然后入库！
这样，一个漏洞就被补上了！

之前写hackinglab教程的时候从别的dalao那里看到这句话还是懵懵懂懂，现在终于看懂了，我们结合一下题目源码看看问题所在

题目主干ba_captcha_bypass.php

在low级别下，首先验证会话变量captcha和POST表单提交的变量captcha_user是否相同，过了这一步才去验证帐号密码的正确性

继续往下，验证码的图片通过iframe标签引用自captcha_box.php

captcha_box.php

也就两行内容，分别是

引用验证码图片captcha.php
重新加载验证码图片的JS语句

验证码图片生成captcha.php

验证码内容调用random_string()函数生成，并将其赋值给会话变量captcha
验证码图片使用imagettftext()函数生成

一共分成3步，2、3步之所以分开的原因是方便重新生成验证码图片

有问题吗？

有的，模拟用户正常登录行为，用户提交错误的帐号、密码、验证码后，登录失败，浏览器由于响应包中包含

<iframe src="captcha_box.php" scrolling="no" frameborder="0" height="70"
width="350"></iframe>

会再去加载captcha_box.php，由于captcha_box.php需要captcha.php生成验证码图片，又会调用captcha.php

如上图所示，而在调用captcha.php的过程中，又会生成新的会话变量captcha，使得正常的登录行为验证码的生成不存在问题

但是使用burp等自动暴力破解工具仅对ba_captcha_bypass.php进行暴力破解，对响应包中要去调用captcha_box.php根本不予例会，更不用说进一步调用captcha.php，所以会话变量captcha一直没有更新，原先的POST字段captcha_user一直是可用的

再说一下medium和high等级下的防御思路

增加了一句

if(isset($_SESSION["captcha"])

判断会话变量captcha是不是存在。。。这个讲道理是不能防止我们上面的攻击思路的，因为我们在第一次模拟正常登录行为的时候是获取了会话变量captcha的

同样我们验证一下

在medium和high level下果然还是可以爆破成功的

那么我们怎么防御这种攻击呢？根据上面的描述

在核对验证码后先将 session 和 cookie 的值清空，然后做数据合法性判断，然后入库

其实我觉得其实改一下high里面的验证代码即可

if(isset($_SESSION["captcha"]) && ($_POST["captcha_user"] == $_SESSION["captcha"]))
    {
        if($_POST["login"] == $login && $_POST["password"] == $password)
        {

            $message = "<font color=\"green\">Successful login!</font>";

        }

        else
        {

            $message = "<font color=\"red\">Invalid credentials! Did you forgot your password?</font>";

        }
    }

里面增加一句unset($_SESSION["captcha"]);

if(isset($_SESSION["captcha"]) && ($_POST["captcha_user"] == $_SESSION["captcha"]))
    {
        if($_POST["login"] == $login && $_POST["password"] == $password)
        {

            $message = "<font color=\"green\">Successful login!</font>";

        }

        else
        {

            $message = "<font color=\"red\">Invalid credentials! Did you forgot your password?</font>";

        }
    unset($_SESSION["captcha"]);
    }