第六关：Insecure CAPTCHA（不安全的验证码）
不安全的验证码？不是这个意思，而是指验证码验证可以被绕过。怎么绕？一般都是验证码的验证和最终修改的验证分离，导致了中间过程（验证码的验证结果）可以被篡改。
low
刚进入DVWA看见报错，意思是验证码的密钥找不到了
需要在..\..\..\DVWA-master\config\config.inc.php配置文件中加入谷歌的密钥：
$_DVWA[ 'recaptcha_public_key' ] = '6LdK7xITAAzzAAJQTfL7fu6I-0aPl8KHHieAT_yJg';
$_DVWA[ 'recaptcha_private_key' ] = '6LdK7xITAzzAAL_uw9YXVUOPoIHPZLfw2K1n5NVQ';
修改保存后，再打开dvwa即可
这是一个修改密码的页面
查看源码，可以看到，服务器将改密操作分成了两步，第一步检查用户输入的验证码，验证通过后，服务器返回表单，第二步客户端提交post请求，服务器完成更改密码的操作。但是，这其中存在明显的逻辑漏洞，服务器仅仅通过检查Change、step 参数来判断用户是否已经输入了正确的验证码。
我们输入新的密码，然后抓包
把step=1改成step=2进行绕过
medium
可以看到，Medium级别的代码在第二步验证时，参加了对参数passed_captcha的检查，如果参数值为true，则认为用户已经通过了验证码检查，然而用户依然可以通过伪造参数绕过验证。
抓包
然后修改参数
修改成功
high
可以看到，服务器的验证逻辑是当$resp（这里是指谷歌返回的验证结果）是对的，或者参数recaptcha_response_field等于hidd3n_valu3并且http包头的User-Agent参数等于reCAPTCHA时，就认为验证码输入正确，满足其一即可
验证码这里肯定是不对的，所以我们只要构造参数即可。
修改成功了
impossible
可以看到，Impossible级别的代码增加了Anti-CSRF token 机制防御CSRF攻击，利用PDO技术防护sql注入，验证过程终于不再分成两部分了，验证码无法绕过，同时要求用户输入之前的密码，进一步加强了身份认证。
