漏洞预警:Joomla! 3.7 Core SQL注入漏洞
妩媚的悟空 2017年05月18日

漏洞预警:Joomla! 3.7 Core SQL注入漏洞

妩媚的悟空 妩媚的悟空 发布于2017年05月18日 收藏 5 评论 13

【上云狂欢节】6元虚机+9元建站+免费套餐,将普惠进行到底!>>>  

2017年5月17日,国外研究人员发现开源CMS软件Joomla!3.7.0 Core 版本里面发现一个SQL注入漏洞攻击,该漏洞风险较高,可能存在数据泄露的风险.

漏洞编号:

CVE-2017-8917

漏洞名称:

Joomla!3.7.0 Core SQL注入漏洞

官方评级:

高危

漏洞描述:

3.7.0新引入的一个组件“com_fields”,这个组件任何人都可以访问,无需登陆验证。由于对请求数据过滤不严导致sql 注入,sql注入对导致数据库中的敏感信息泄漏,例如用户的密码hash以及登陆后的用户的session(如果是获取到登陆后管理员的session,那么整个网站的后台系统可能被控制)。

漏洞利用条件和方式:

直接远程利用

漏洞影响范围:

Joomla! 3.7.0 Core

漏洞检测:

漏洞修复建议(或缓解措施):

目前官方发布最新版本,建议尽快安装补丁:https://downloads.joomla.org/cms/joomla3/3-7-1

本站文章除注明转载外,均为本站原创或编译。欢迎任何形式的转载,但请务必注明出处,尊重他人劳动共创开源社区。
转载请注明:文章转载自 开源中国社区 [http://www.oschina.net]
本文标题:漏洞预警:Joomla! 3.7 Core SQL注入漏洞
分享
评论(13)
最新评论
0

引用来自“eechen”的评论

预处理参数化查询能够防御SQL注入.
数据库真实预处理的本质是分离SQL模板和SQL参数.

但并非所有数据库都支持预处理,像SQLite就不支持.
所以PHP提供了模拟预处理(默认开启),其本质是转义用户输入,相关函数是:
PDO::quote和mysqli_real_escape_string.
在模拟预处理下,绑定参数(bindParam/bind_param)本质也是转义,而非SQL模板和参数分离.

安全的转义依赖统一的编码:
http://php.net/mysqli_real_escape_string
http://php.net/manual/zh/mysqlinfo.concepts.charset.php
MySQLi中需要先用 $mysqli->set_charset('utf8') 定义字符集后,
才能确保 $mysqli->real_escape_string() 能够安全正确转义用户输入的字符串.
PDO_MySQL中需要在PDO()中用 charset=utf8 定义字符集后,
才能确保 PDO::quote() 能够安全正确转义用户输入的字符串.
PHP模拟预处理时,PDO的bindParam/bindValue/execute转义时底层用的应该也是PDO::quote().
@eechen 别复制粘贴了,快去应战啊
0

引用来自“eechen”的评论

预处理参数化查询能够防御SQL注入.
数据库真实预处理的本质是分离SQL模板和SQL参数.

但并非所有数据库都支持预处理,像SQLite就不支持.
所以PHP提供了模拟预处理(默认开启),其本质是转义用户输入,相关函数是:
PDO::quote和mysqli_real_escape_string.
在模拟预处理下,绑定参数(bindParam/bind_param)本质也是转义,而非SQL模板和参数分离.

安全的转义依赖统一的编码:
http://php.net/mysqli_real_escape_string
http://php.net/manual/zh/mysqlinfo.concepts.charset.php
MySQLi中需要先用 $mysqli->set_charset('utf8') 定义字符集后,
才能确保 $mysqli->real_escape_string() 能够安全正确转义用户输入的字符串.
PDO_MySQL中需要在PDO()中用 charset=utf8 定义字符集后,
才能确保 PDO::quote() 能够安全正确转义用户输入的字符串.
PHP模拟预处理时,PDO的bindParam/bindValue/execute转义时底层用的应该也是PDO::quote().
这个 @eechen 就是个笑话,天天要喊着吊打,结果现在挂在树上惨遭吊打,屁都不敢放一个,又一个神棍被拉下神坛 --via FalconChen . 有链接有真相: https://www.oschina.net/question/253880_2236467
0
预处理参数化查询能够防御SQL注入.
数据库真实预处理的本质是分离SQL模板和SQL参数.

但并非所有数据库都支持预处理,像SQLite就不支持.
所以PHP提供了模拟预处理(默认开启),其本质是转义用户输入,相关函数是:
PDO::quote和mysqli_real_escape_string.
在模拟预处理下,绑定参数(bindParam/bind_param)本质也是转义,而非SQL模板和参数分离.

安全的转义依赖统一的编码:
http://php.net/mysqli_real_escape_string
http://php.net/manual/zh/mysqlinfo.concepts.charset.php
MySQLi中需要先用 $mysqli->set_charset('utf8') 定义字符集后,
才能确保 $mysqli->real_escape_string() 能够安全正确转义用户输入的字符串.
PDO_MySQL中需要在PDO()中用 charset=utf8 定义字符集后,
才能确保 PDO::quote() 能够安全正确转义用户输入的字符串.
PHP模拟预处理时,PDO的bindParam/bindValue/execute转义时底层用的应该也是PDO::quote().
0

引用来自“eechen”的评论

预处理参数化查询能够防御SQL注入.
数据库真实预处理的本质是分离SQL模板和SQL参数.

但并非所有数据库都支持预处理,像SQLite就不支持.
所以PHP提供了模拟预处理(默认开启),其本质是转义用户输入,相关函数是:
PDO::quote和mysqli_real_escape_string.
在模拟预处理下,绑定参数(bindParam/bind_param)本质也是转义,而非SQL模板和参数分离.

安全的转义依赖正确的编码:
http://php.net/mysqli_real_escape_string
http://php.net/manual/zh/mysqlinfo.concepts.charset.php
MySQLi中需要先用 $mysqli->set_charset('utf8') 定义字符集后,
才能确保 $mysqli->real_escape_string() 能够安全正确转义用户输入的字符串.
PDO_MySQL中需要在PDO()中用 charset=utf8 定义字符集后,
才能确保 PDO::quote() 能够安全正确转义用户输入的字符串.
PHP模拟预处理时,PDO的bindParam/bindValue/execute转义时底层用的应该也是PDO::quote().
这个 @eechen 就是个笑话,天天要喊着吊打,结果现在挂在树上惨遭吊打,屁都不敢放一个,又一个神棍被拉下神坛 --via FalconChen . 有链接有真相: https://www.oschina.net/question/253880_2236467
0

引用来自“风水书生”的评论

为啥php真么多sql注入的?
这跟语言无关,跟使用语言的人有关
0
为啥php真么多sql注入的?
0

引用来自“首席打酱油”的评论

哪位php大神告诉我为什么WordPress一天到晚的sql注入这么低级的漏洞
你先找一个同样丰富功能的开源替代品,咱们再聊这个问题
0
‘’
0
这都什么念头了,SQL注入这种漏洞~~~
0
只要存在SQL语句的字符串拼接,就必然存在SQL注入风险
0
开源软件代码是裸露的.要保证100%无BUG真心难.
0
第一句话是病句。
0
消灭沙发

相关资讯

最新资讯
热门资讯
顶部