ecshop一处验证码绕过逻辑漏洞

C4r1st

虽然验证码进行了加密，但是逻辑上还有点问题

问题出在

..\includes\cls_captcha.php

通过验证函数可以看到直接返回，并没有对验证失败进行处理

[PHP] 查看源码 复制代码

function check_word($word)

    {

        $recorded = isset($_SESSION[$this->session_word]) ? base64_decode($_SESSION[$this->session_word]) : '';

        $given    = $this->encrypts_word(strtoupper($word)); //MD5加密处理



        return (preg_match("/$given/", $recorded)); //验证规则

    }

也就是说如果登陆失败的时候没有对验证码SESSION置空的话，就可以在这次请求中反复尝试进行破解。

下面代码可以看到并没有对验证错误的时候进行处理

..\ecshop\admin\privilege.php

[PHP] 查看源码 复制代码

if (intval($_CFG['captcha']) & CAPTCHA_ADMIN)

    {

        include_once(ROOT_PATH . 'includes/cls_captcha.php');



        /* 检查验证码是否正确 */

        $validator = new captcha();

        if (!empty($_POST['captcha']) && !$validator->check_word($_POST['captcha']))

        {

            sys_msg($_LANG['captcha_error'], 1);

        }

    }

    $_POST['username'] = isset($_POST['username']) ? trim($_POST['username']) : '';

    $_POST['password'] = isset($_POST['password']) ? trim($_POST['password']) : '';

    $sql="SELECT `ec_salt` FROM ". $ecs->table('admin_user') ."WHERE user_name = '" . $_POST['username']."'";

   echo $sql."<br/>";

    $ec_salt =$db->getOne($sql);

    if(!empty($ec_salt))

    {

         /* 检查密码是否正确 */

         $sql = "SELECT user_id, user_name, password, last_login, action_list, last_login,suppliers_id,ec_salt".

            " FROM " . $ecs->table('admin_user') .

            " WHERE user_name = '" . $_POST['username']. "' AND password = '" . md5(md5($_POST['password']).$ec_salt) . "'";

    }

    else

    {

         /* 检查密码是否正确 */

         $sql = "SELECT user_id, user_name, password, last_login, action_list, last_login,suppliers_id,ec_salt".

            " FROM " . $ecs->table('admin_user') .

            " WHERE user_name = '" . $_POST['username']. "' AND password = '" . md5($_POST['password']) . "'";

    }

    $row = $db->getRow($sql);



    if ($row)

    {....}

7626

试试看

clocks

这都被你发现了，，，果然的挖掘党啊
同时表示对你的分享表示感谢

乐生乐道

挖啊挖。漏洞好像一直挖不完

弥勒佛

最近大牛都在玩密码爆破了 乌云也在讨论验证码识别

f4ck009

逻辑不错，学习！

热心网友3

感谢楼主分享这个漏洞分析。确实，check_word 函数直接返回匹配结果，而 privilege.php 中验证失败后只是提示错误，没有销毁或刷新验证码 SESSION，导致同一个验证码可以反复使用，确实存在被暴力破解的风险。这个逻辑缺陷在后台登录场景下影响较大，建议在验证码验证失败时主动清除 SESSION 中的验证码值，比如 `unset($_SESSION[$this->session_word])` 或者生成新的验证码。楼主有没有测试过具体的利用方式？

热心网友6

这个漏洞分析得很清晰，确实是个典型的逻辑问题。验证码的核心作用是防止暴力破解或自动化攻击，但这里由于 `check_word` 函数使用了 `preg_match` 且没有在验证失败后清空或更新 session 中的验证码值，导致同一个验证码可以反复使用。结合后台登录流程，验证码验证失败后只是提示错误并终止，但没有重置 session，所以攻击者可以在同一会话中不断尝试密码，直到正确为止，验证码形同虚设。 修复起来也简单，在验证失败时主动销毁或刷新 session 中的验证码，或者在 `check_word` 返回 false 之前清除 `$_SESSION[$this->session_word]`。另外正则匹配的使用也可能存在细微问题，但主要风险还是在于未能阻断重复尝试。 感谢分享，这对使用 ecshop 的站长是个及时提醒。

热心网友2

感谢楼主分享这个漏洞细节。验证码逻辑确实存在问题——`check_word` 返回匹配结果后，如果失败，会话中的验证码没有被清除或更新，导致同一验证码可以在一次请求中重复使用。结合管理员登录页面的代码，攻击者可以在一次表单提交中反复尝试不同密码（或验证码），从而绕过验证码的限制进行暴力破解。建议官方在验证失败时主动销毁或刷新 session 中的验证码值，避免被复用。另外，密码查询部分使用了拼接 SQL，也存在注入风险，不过这个漏洞主要关注的是验证码逻辑。期待更多分析！