Joomla 密码重置漏洞是如何工作的？
我们的一个 Joomla 网站遭到黑客攻击，攻击者用他丑陋的页面替换了我模板的 index.php - “Hacked”标题和一些红色的阿拉伯文行。 显然，攻击者如何重置用户表中第一个用户（即超级用户）的密码（以及电子邮件地址），并获得对管理面板的访问权限。
快速恢复后，我搜索网络以防止将来的黑客尝试，并找到这篇文章： 安全新闻-[20080801] - 核心 - 密码提醒功能
我用那篇文章中的代码来修补我的reset.php
但我仍然有疑问。 这篇文章没有说明该漏洞是如何真正发挥作用的。 但我在互联网上读到这是reset.php中的一个SQL注入漏洞
执行SQL来检查令牌的行：
$db->setQuery('SELECT id FROM #__users
WHERE block = 0
AND activation = '.$db->Quote($token));
正在使用JDatabase::Quote()方法。那么SQL注入是如何成为可能的呢？ Quote 不是应该阻止 SQLi 吗？ 被攻击网站的 Joomla 版本是 1.5.18。
另一个疑问是补丁检查仅验证字符串长度为32。如何防止漏洞利用。
我想知道 SQLi 是否真的可以通过 Quote 方法，那么 32 的字符串长度是否足以绕过 WHERE 子句？
if(strlen($token) != 32) {
$this->setError(JText::_('INVALID_TOKEN'));
return false;
}
One of our Joomla sites got hacked and the attacker replaced my template's index.php with his ugly page - "Hacked" heading and some arabic lines in red.
Apparently, the attacker some how reset the password(and email address too) of first user in the users table, which was the super user, and gained access to administration panel.
After doing a quick recovery, I searched net to prevent future hacking attempt and found this article: Security News-[20080801] - Core - Password Remind Functionality
I put the code from that article to patch my reset.php
But I am still having doubts.
The article doesn't say anything about how the exploit really work.
But I read some where in the internet that this is an SQL injection vulnerability in reset.php
The line executing SQL to check the token:
$db->setQuery('SELECT id FROM #__users
WHERE block = 0
AND activation = '.$db->Quote($token));
is using the JDatabase::Quote() method. Then how does some SQL injection become possible. Isn't Quote supposed to prevent an SQLi?
Joomla version of attacked site is 1.5.18.
Another doubt is in the patch checking only to verify string length of 32. How could it prevent the exploit.
I'm wondering if an SQLi can really pass Quote method then wouldn't a string length of 32 be more than enough to bypass that WHERE clause?
if(strlen($token) != 32) {
$this->setError(JText::_('INVALID_TOKEN'));
return false;
}
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
问题在于令牌值根本没有经过验证，而只是清除了非字母数字字符。 利用是只输入一个被过滤掉的
'因此有效令牌值是一个空字符串，结果如下：The problem was that the token value was not validated at all but only cleaned from non-alphanumeric characters. And the exploit was to just enter a single
'that was filtered out so that the effective token value was an empty string that resulted in something like this: