电子商务服务平台CubeCart两个高危漏洞，陷用户于风险之中

CubeCart是一个开源的电子商务解决方案，你可利用它把各种网上商城系统集成到一起，这样你的PC，手机浏览器，微信，App，平板等多个客户终端都会绑定在一起。虽然这为你全面打通了所有用户设备，用起来很方便，但也很容易发生系统性风险，如果CubeCart出现漏洞，则绑定的这些设备都会遭殃。

一旦攻击者利用漏洞通过管理员权限控制网站服务器，则就会构成信息泄露和运行安全风险。这种情况并不是没有发生过，在2013年一月，CubeCart就出现过CubeCart 'redir'参数开放重定向漏洞、CubeCart目录遍历漏洞、CubeCart权限提升漏洞、CubeCart SQL注入漏洞。其中，“CubeCart权限提升漏洞”和“CubeCart SQL注入漏洞”的综合评级均为“高危”。

时隔5年，研究人员又在CubeCart 6.1.12版本中发现了两个漏洞，它们可以允许攻击者绕过所需的身份验证机制，以管理员身份登录。一旦被绕过，攻击者就可以在网站服务器上执行任意代码并窃取所有敏感文件和数据。

本文将仔细介绍一下这些漏洞，并顺便让你了解一下这些自定义的数据库抽象层是如何蚕食你的。

通过重置密码来做文章

passwordReset()方法首先会检查电子邮件是否是有效的电子邮件地址，如果所有参数都是非空的，在680-683行的密码是相同的。如果其中一个检查失败，则密码重置进度将在第694行失败。否则，下一个检查是由685-687行中的select()调用发出的数据库查询。此时，用户提供的$email和$verification令牌被用作参数。

select()方法构造了一个SQL查询，然后发送到数据库的第576行。要构建SELECT查询的WHERE子句，应用程序就要使用第574行的()中的漏洞方法。接下来，我将分析这个where()方法并介绍两个检测到的漏洞。

未经身份验证的盲注SQL

如果我是攻击者，那现在就可以将数组作为用户输入进行传递。这样我就可以将SQL语法注入到构造的SQL查询中，并执行SQL注入攻击以从数据库中提取敏感信息。恶意的POST请求可能如下所示：

这样validate输入参数现在就是一个不包含有效密码重置标记的数组，而是SQL载荷。构建的SQL查询可以在下面看到（注入部分标记为红色）。

这样，攻击者就可以修改SQL查询并开始提取所有用户的密码哈希值，或者将更复杂的攻击转移到解除操作系统的数据库上。但其实，还有一个更简单的方法可以进行身份验证，该方法甚至不用窃取和破解管理员的密码哈希。

绕过身份验证

基本上，where()方法检查特殊字符（〜！+ - ）的输入值，则会最终影响在SQL查询的WHERE子句中所使用的比较运算符。例如，值中的前缀代字符（〜）将用LIKE语法（第817-818行）构造SQL查询。LIKE操作不需要数据库中的精确匹配，但允许使用通配符（％）。这可以被滥用绕过对有效的密码重置令牌的检查。而我所要做的就是在我的密码重置标记前添加一个〜字符，并将许多通配符输入到密码重置令牌中，就像预期的令牌长度一样，这将导致以下SELECT查询。

需要一个正确的验证令牌的WHERE条件，在我们精心设计的验证令牌中几乎所有时间都将被评估为true，因此这个验证可以被轻松忽略。这就允许攻击者在几秒钟内重置管理员的密码并以管理员身份登录。在管理面板中，攻击者可以滥用管理功能来执行任意PHP代码。

总结

这两个漏洞都允许攻击者绕过CubeCart的身份验证并以管理员身份登录，本质上，这个安全问题是基于自定义数据库抽象层，以不安全的方式编译SQL查询。 由于缺少准备好的语句和自定义的SQL连接功能，攻击者可能会扭曲用于身份验证的SQL查询，以便绕过它。

在此，我要感谢CubeCart团队对这些问题的快速和专业的处理。目前， CubeCart 6.1.13更新已经发布，请赶紧更新。