Joomla 3.4.3版本 SQL注入漏洞分析

本文涉及的产品
Web应用防火墙 3.0,每月20元额度 3个月
云安全中心 免费版,不限时长
云安全中心 防病毒版,最高20核 3个月
简介:

0x00 漏洞分析

漏洞触发的代码位于:/administrator/components/com_contenthistory/models/history.php,getListQuery()函数内:


通过SQL及报错信息,可以知道我们的注入payload被插入到了红色框部分内。跟进getState()函数,位于libraries/legacy/model/legacy.php文件内,代码如下:


从函数参数和官方注释,可以知道,getState()函数功能是获取一个model的属性及属性对应的值,getState()函数在model的属性未设置时,会执行$this->populateState()来对model的一些属性进行赋值操作。

我们跟进populateState()函数看下做了什么操作,代码位于:/administrator/components/com_contenthistory/models/history.php 内:


该函数从用户输入中取出item_id,type_id,type_alias,等几个变量,对当前model的属性进行赋值,可控变量均强制为integer类型,无法利用。顺着最后一行代码:parent::populateState(‘h.save_date’, ‘DESC’),继续跟到父类中看父类populateState()函数的定义,代码位于:libraries/legacy/model/list.php,482行附近:


getUserStateFromRequest()函数用于将GET/POST中得list[]变量取回到$list中,并在第三个参数中指定该变量类型为array(),继续跟进:


代码对取到的list[]数组进行了遍历,并做相应的过滤、拆分,可以看到list[select]没有处理逻辑,会进入default的case,后续$this->setState(‘list.’ . $name, $value)代码执行后,导致请求中list[select]变量没有任何变量被直接赋值给Model属性,继续回头看文章最开始的注入位置,此时我们可以控制$this->getState(‘list.select’)的返回值,构造SQL注入。

确认了输入可控的位置,构造有效的payload,还需要解决几个小问题。构造POC:

index.php?option=com_contenthistory&view=history&item_id=1&type_id=1&list[select]=(exp(~(select * from(select md5(1))x)))

会发现出现错误提示 Unknown column ‘Array’:


需要增加list[ordering]=将原SQL中的order by字段值清空。
最终可执行POC:

/index.php?option=com_contenthistory&view=history&item_id=1&list[ordering]=&type_id=1&list[select]=(exp(~(select * from(select md5(1))x)))

执行会返回:


此带回显POC成功执行需要一个前提条件,就是传入的item_id 可以在Joomla_ucm_history表中查询到,否则会返回“500 – Layout default not found.”的提示。根据原文描述,可以暴力猜解item_id或使用time_based payload,不再赘述。

0x01 漏洞影响

joomla3.2-3.4.4版本

0x02 修复方案

目前Joomla官方已经跟新3.4.5版本,用户可登陆后台进行更新。
或下载官方升级包升级,下载地址:
https://github.com/joomla/joomla-cms/releases

0x03 参考链接

https://www.trustwave.com/Resources/SpiderLabs-Blog/Joomla-SQL-Injection-Vulnerability-Exploit-Results-in-Full-Administrative-Access/

作者:云盾攻防对抗团队 - 千霄

发表日期:2015年10月23日


目录
相关文章
|
1月前
|
SQL 存储 数据可视化
手机短信SQL分析技巧与方法
在手机短信应用中,SQL分析扮演着至关重要的角色
|
1月前
|
SQL 监控 测试技术
SQL现在到哪个版本及版本更新技巧与方法
SQL(Structured Query Language)作为数据库管理和操作的标准语言,随着技术的不断进步和数据库管理系统(DBMS)的持续发展,其版本也在不断更新和完善
|
1月前
|
SQL Oracle 关系型数据库
SQL数据库当前版本概览与更新趋势
在探讨SQL(Structured Query Language)数据库的当前版本时,我们首先要明确的是,SQL本身是一种查询语言标准,而并非特指某一个具体的数据库产品
|
25天前
|
SQL 关系型数据库 MySQL
MySql5.6版本开启慢SQL功能-本次采用永久生效方式
MySql5.6版本开启慢SQL功能-本次采用永久生效方式
36 0
|
2月前
|
SQL 安全 数据库
惊!Python Web安全黑洞大曝光:SQL注入、XSS、CSRF,你中招了吗?
在数字化时代,Web应用的安全性至关重要。许多Python开发者在追求功能时,常忽视SQL注入、XSS和CSRF等安全威胁。本文将深入剖析这些风险并提供最佳实践:使用参数化查询预防SQL注入;通过HTML转义阻止XSS攻击;在表单中加入CSRF令牌增强安全性。遵循这些方法,可有效提升Web应用的安全防护水平,保护用户数据与隐私。安全需持续关注与改进,每个细节都至关重要。
134 5
|
2月前
|
SQL 安全 数据库
深度揭秘:Python Web安全攻防战,SQL注入、XSS、CSRF一网打尽!
在Web开发领域,Python虽强大灵活,却也面临着SQL注入、XSS与CSRF等安全威胁。本文将剖析这些常见攻击手段,并提供示例代码,展示如何利用参数化查询、HTML转义及CSRF令牌等技术构建坚固防线,确保Python Web应用的安全性。安全之路永无止境,唯有不断改进方能应对挑战。
69 5
|
1月前
|
SQL 运维 安全
怎样可以找到SQL漏洞:技巧与方法详解
SQL漏洞,特别是SQL注入漏洞,是Web应用中常见的安全威胁之一
|
2月前
|
SQL 安全 数据安全/隐私保护
Python Web安全大挑战:面对SQL注入、XSS、CSRF,你准备好了吗?
在构建Python Web应用时,安全性至关重要。本文通过三个真实案例,探讨了如何防范SQL注入、XSS和CSRF攻击。首先,通过参数化查询替代字符串拼接,防止SQL注入;其次,利用HTML转义机制,避免XSS攻击;最后,采用CSRF令牌验证,保护用户免受CSRF攻击。这些策略能显著增强应用的安全性,帮助开发者应对复杂的网络威胁。安全是一个持续的过程,需不断学习新知识以抵御不断变化的威胁。
117 1
|
2月前
|
SQL 安全 数据库
Python Web开发者必看!SQL注入、XSS、CSRF全面解析,守护你的网站安全!
在Python Web开发中,构建安全应用至关重要。本文通过问答形式,详细解析了三种常见Web安全威胁——SQL注入、XSS和CSRF,并提供了实用的防御策略及示例代码。针对SQL注入,建议使用参数化查询;对于XSS,需对输出进行HTML编码;而防范CSRF,则应利用CSRF令牌。通过这些措施,帮助开发者有效提升应用安全性,确保网站稳定运行。
47 1
|
2月前
|
SQL 安全 数据库
深度揭秘:Python Web安全攻防战,SQL注入、XSS、CSRF一网打尽!
在Web开发领域,Python虽强大灵活,但安全挑战不容小觑。本文剖析Python Web应用中的三大安全威胁:SQL注入、XSS及CSRF,并提供防御策略。通过示例代码展示如何利用参数化查询、HTML转义与CSRF令牌构建安全防线,助您打造更安全的应用。安全是一场持久战,需不断改进优化。
48 3
下一篇
无影云桌面