CI框架中的SQL注入隐患
0x00
在CI框架中,获取get和post参数是使用了$this->input类中的get和post方法。
其中,如果get和post方法的第二个参数为true,则对输入的参数进行XSS过滤,注意只是XSS过滤,并不会对SQL注入进行有效的防范。
例子:
Controller中,定义一个shit方法,获取get数据:
指定了第二个参数为true:
(1)XSS测试
(2)SQL注入测试
并不会对单引号进行处理。
例子在程式舞曲CMS中,该CMS是基于CI框架进行开发的CMS:
这里的变量只有post的xss过滤,无法防范SQL注入。
使用了拼接的SQL语句,直接带入数据库查询:
0x01
在CI框架中,尽量使用AR类进行数据库查询是比较靠谱的,因为在底层会帮助使用者进行一次有效的转义,但也仅仅是转义而已。
过滤的方法是escape_str() :
function escape_str($str, $like = FALSE) { var_dump($str); echo "\n" ; if (is_array($str)) { foreach ($str as $key => $val) { $str[$key] = escape_str($val, $like); } return $str; } if (function_exists('mysql_real_escape_string')) { $str = addslashes($str); } elseif (function_exists('mysql_escape_string')) { $str = mysql_escape_string($str); } else { $str = addslashes($str); } // escape LIKE condition wildcards if ($like === TRUE) { $str = str_replace(array('%', '_'), array('\\%', '\\_'), $str); } return $str; }
该方法仅仅是调用了一些转义函数,并对like参数进行过滤。
如果查询的变量没有被单引号包裹,那么就无法进行保护:
0x02
AR类的过滤方案是没有考虑数组的key值的,纵观各大CMS出现的SQL注入,由于数组的$key过滤不严直接带入SQL查询的漏洞屡见不鲜。
输出为:
0x03
CI框架开发速度快,轻巧,并且不用单独学习一门模板语言也可以使用。但是如果对CI框架中自带的安全机制理解不透彻,会导致无穷无尽的漏洞,程式舞曲CMS就是个很好的例子,被草了这么多回,代码还是这么烂,直接在controller里写SQL,说好的model呢。
郑重声明:本站内容如果来自互联网及其他传播媒体,其版权均属原媒体及文章作者所有。转载目的在于传递更多信息及用于网络分享,并不代表本站赞同其观点和对其真实性负责,也不构成任何其他建议。