【DVWA】验证码攻防对抗实战

此心光明，亦复何言

0.Insecure CAPTCHA

"Insecure CAPTCHA" 指的是一种设计或实现不安全的 CAPTCHA（完全自动化的公共图灵测试区分计算机和人类）机制。CAPTCHA 通常用于防止自动化程序（如机器人）滥用网站服务，要求用户输入图像、音频或其他形式的识别测试。

然而，如果 CAPTCHA 系统存在设计或实现上的漏洞或弱点，它可能会被绕过或破解，从而使得自动化程序仍能轻松通过验证，这种情况就被称为 "Insecure CAPTCHA"。一些常见的导致 CAPTCHA 不安全的原因包括：

1. 图像识别算法弱：某些 CAPTCHA 图像的扭曲程度较低，导致图像识别算法（如 OCR 技术）可以轻松破解。

2. 预生成验证码：有些网站使用了预先生成的、易于破解的验证码，这使得攻击者可以利用字典攻击或暴力破解技术绕过验证。

3. 易受机器学习攻击：随着机器学习技术的发展，攻击者可以训练模型识别复杂的 CAPTCHA 测试，导致其安全性大幅下降。

4. 人机验证机制不充分：一些 CAPTCHA 系统设计上不够复杂或没有足够的变化，容易被自动化工具识别或绕过。

为了解决这些问题，现代的 CAPTCHA 系统（例如 Google 的 reCAPTCHA）通常会采用更复杂的验证方式，如行为分析、点击或拖动验证等，同时增强抗破解能力，以确保机器人无法轻易通过测试。

1.Insecure CAPTCHA(Low)

相关代码分析

<?php

if( isset( $_POST[ 'Change' ] ) && ( $_POST[ 'step' ] == '1' ) ) {
// Hide the CAPTCHA form
$hide_form = true;

// Get input
$pass_new  = $_POST[ 'password_new' ];
$pass_conf = $_POST[ 'password_conf' ];

// Check CAPTCHA from 3rd party
$resp = recaptcha_check_answer(
$_DVWA[ 'recaptcha_private_key'],
$_POST['g-recaptcha-response']
);

// Did the CAPTCHA fail?
if( !$resp ) {
// What happens when the CAPTCHA was entered incorrectly
$html     .= "<pre><br />The CAPTCHA was incorrect. Please try again.</pre>";
$hide_form = false;
return;
}
else {
// CAPTCHA was correct. Do both new passwords match?
if( $pass_new == $pass_conf ) {
// Show next stage for the user
$html .= "
<pre><br />You passed the CAPTCHA! Click the button to confirm your changes.<br /></pre>
<form action="#" method="POST">
<input type="hidden" name="step" value="2" />
<input type="hidden" name="password_new" value="{$pass_new}" />
<input type="hidden" name="password_conf" value="{$pass_conf}" />
<input type="submit" name="Change" value="Change" />
</form>";
}
else {
// Both new passwords do not match.
$html     .= "<pre>Both passwords must match.</pre>";
$hide_form = false;
}
}
}

if( isset( $_POST[ 'Change' ] ) && ( $_POST[ 'step' ] == '2' ) ) {
// Hide the CAPTCHA form
$hide_form = true;

// Get input
$pass_new  = $_POST[ 'password_new' ];
$pass_conf = $_POST[ 'password_conf' ];

// Check to see if both password match
if( $pass_new == $pass_conf ) {
// They do!
$pass_new = ((isset($GLOBALS["___mysqli_ston"]) && is_object($GLOBALS["___mysqli_ston"])) ? mysqli_real_escape_string($GLOBALS["___mysqli_ston"],  $pass_new ) : ((trigger_error("[MySQLConverterToo] Fix the mysql_escape_string() call! This code does not work.", E_USER_ERROR)) ? "" : ""));
$pass_new = md5( $pass_new );

// Update database
$insert = "UPDATE `users` SET password = '$pass_new' WHERE user = '" . dvwaCurrentUser() . "';";
$result = mysqli_query($GLOBALS["___mysqli_ston"],  $insert ) or die( '<pre>' . ((is_object($GLOBALS["___mysqli_ston"])) ? mysqli_error($GLOBALS["___mysqli_ston"]) : (($___mysqli_res = mysqli_connect_error()) ? $___mysqli_res : false)) . '</pre>' );

// Feedback for the end user
$html .= "<pre>Password Changed.</pre>";
}
else {
// Issue with the passwords matching
$html .= "<pre>Passwords did not match.</pre>";
$hide_form = false;
}

((is_null($___mysqli_res = mysqli_close($GLOBALS["___mysqli_ston"]))) ? false : $___mysqli_res);
}

?>

可以看到，服务器将改密操作分成了两步，第一步检查用户输入的验证码，验证通过后，服务器返回表单，第二步客户端提交post请求，服务器完成更改密码的操作。但是，这其中存在明显的逻辑漏洞，服务器仅仅通过检查Change、step 参数来判断用户是否已经输入了正确的验证码。

通过构造参数绕过验证过程的第一步

首先输入密码，点击Change按钮，抓包：

（ps:因为没有翻墙，所以没能成功显示验证码，发送的请求包中也就没有recaptcha_challenge_field、recaptcha_response_field两个参数）

更改step参数为2绕过验证码：

修改密码成功：

2.Insecure CAPTCHA(Medium)

相关代码分析

可以看到，Medium级别的代码在第二步验证时，参加了对参数passed_captcha的检查，如果参数值为true，则认为用户已经通过了验证码检查，然而用户依然可以通过伪造参数绕过验证，本质上来说，这与Low级别的验证没有任何区别。

1.可以通过抓包，更改step参数，增加passed_captcha参数，绕过验证码。

抓到的包：

更改之后的包：passed_captcha=true

更改密码成功：

3.Insecure CAPTCHA(High)

相关代码分析

在High级别中, 去掉了逻辑漏洞的成因----step, 而且加入了防CSRF机制。

漏洞利用

仔细审查代码, 可以看到服务器的验证逻辑是当参数 resp（这里是指谷歌验证码返回的验证结果）是false，并且参数recaptcha_response_field不等于hidd3n_valu3（或者http包头的User-Agent参数不等于reCAPTCHA）时，就认为验证码输入错误，反之则认为已经通过了验证码的检查。

弄清楚了逻辑, 存在的逻辑漏洞就是 || (异或条件), 只要我们抓包修改一下参数值:

recaptcha_response_field=hidd3n_valu3

User-Agent: reCAPTCHA

再提交就可以绕过了:

先抓包

修改后的包

由于有墙，未能复现成功

4.Insecure CAPTCHA(Impossible)

相关代码分析

可以看到，Impossible级别的代码增加了Anti-CSRF token 机制防御CSRF攻击

利用PDO技术防护sql注入，验证过程终于不再分成两部分了，验证码无法绕过，同时要求用户输入之前的密码，进一步加强了身份认证。

文笔生疏，措辞浅薄，望各位大佬不吝赐教，万分感谢。

原文始发于微信公众号（儒道易行）：【DVWA】验证码攻防对抗实战