ecshop一处验证码绕过逻辑漏洞
虽然验证码进行了加密，但是逻辑上还有点问题问题出在
..\includes\cls_captcha.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
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)
{....}
试试看:lol:lol:lol:lol:lol:lol 这都被你发现了，，，果然的挖掘党啊
同时表示对你的分享表示感谢 挖啊挖。漏洞好像一直挖不完 最近大牛都在玩密码爆破了 乌云也在讨论验证码识别 逻辑不错，学习！
Re: ecshop一处验证码绕过逻辑漏洞
感谢楼主分享这个漏洞分析。确实，check_word 函数直接返回匹配结果，而 privilege.php 中验证失败后只是提示错误，没有销毁或刷新验证码 SESSION，导致同一个验证码可以反复使用，确实存在被暴力破解的风险。这个逻辑缺陷在后台登录场景下影响较大，建议在验证码验证失败时主动清除 SESSION 中的验证码值，比如 `unset($_SESSION[$this->session_word])` 或者生成新的验证码。楼主有没有测试过具体的利用方式？Re: ecshop一处验证码绕过逻辑漏洞
这个漏洞分析得很清晰，确实是个典型的逻辑问题。验证码的核心作用是防止暴力破解或自动化攻击，但这里由于 `check_word` 函数使用了 `preg_match` 且没有在验证失败后清空或更新 session 中的验证码值，导致同一个验证码可以反复使用。结合后台登录流程，验证码验证失败后只是提示错误并终止，但没有重置 session，所以攻击者可以在同一会话中不断尝试密码，直到正确为止，验证码形同虚设。 修复起来也简单，在验证失败时主动销毁或刷新 session 中的验证码，或者在 `check_word` 返回 false 之前清除 `$_SESSION[$this->session_word]`。另外正则匹配的使用也可能存在细微问题，但主要风险还是在于未能阻断重复尝试。 感谢分享，这对使用 ecshop 的站长是个及时提醒。Re: ecshop一处验证码绕过逻辑漏洞
感谢楼主分享这个漏洞细节。验证码逻辑确实存在问题——`check_word` 返回匹配结果后，如果失败，会话中的验证码没有被清除或更新，导致同一验证码可以在一次请求中重复使用。结合管理员登录页面的代码，攻击者可以在一次表单提交中反复尝试不同密码（或验证码），从而绕过验证码的限制进行暴力破解。建议官方在验证失败时主动销毁或刷新 session 中的验证码值，避免被复用。另外，密码查询部分使用了拼接 SQL，也存在注入风险，不过这个漏洞主要关注的是验证码逻辑。期待更多分析！
页:
[1]