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

0x01 背景

现在的WEB应用对SQL注入的防护基本都是判断GPC是否开启,然后使用addlashes函数对单引号等特殊字符进行转义。但仅仅使用这样的防护是存在很多盲点的,比如最经典的整型参数传递,也即被带入数据库查询的参数是整型、数组中的key没过滤被带入了查询以及全局过滤了GET、POST但没过滤SERVER或COOKIE引发的注入。所以看似有全局防护,实则隐藏了很多“后门”~
盲点如下:
①注入点类似id=1这种整型的参数就会完全无视GPC的过滤;
②注入点包含键值对的,那么这里只检测了value,对key的过滤就没有防护;
③有时候全局的过滤只过滤掉GET、POST和COOKIE,但是没过滤SERVER。
附常见的SERVER变量(具体含义自行百度):QUERY_STRING,X_FORWARDED_FOR,CLIENT_IP,HTTP_HOST,ACCEPT_LANGUAGE

0x02 环境搭建

环境请自行搜寻和搭建吧,从这篇开始只做分析不提供漏洞测试环境~~

0x03 漏洞分析

完全无视GPC的数字型的注入,其实仔细总结下发现还是很多可以学习的地方。

1.传入的参数未做intval转换、构造的sql语句没有单引号保护

这个还是比较常见的,当初笔者挖到过一些,乌云案例http://www.wooyun.org/bugs/wooyun-2010-065605

<?phprequire_once "admin/common.php";require_once(MOBAN_PATH_QZ."header.html");//这里typeid没有做整形转换$typeid=isset($_GET[‘typeid‘]) ? $_GET[‘typeid‘] : 1;//sql语句没有单引号保护$type=$db->fetch_array(mysql_query($sql="select * from ".$db->tablepre."newstype where newstypeid=".$typeid));//typeid参数存在注入,数字型;?>

获取管理员账户密码的POC:

http://localhost/jdy1.5/typeid.php?typeid=1 and 1=2 UNION SELECT NULL,(select concat(username,0x23,password) from jdy_admin limit 1),NULL,

2.同一参数在第一个sql里做了单引号保护,紧跟第二个忘记加单引号

有幸在Discuz!上看到此类问题,膜拜下雨牛的漏洞http://www.wooyun.org/bugs/wooyun-2014-079045
简单分析下漏洞原理
首先$itemid经过的第一条SQL语句如下

$query = $_SGLOBAL[‘db‘]->query(‘SELECT * FROM ‘.tname(‘spacetags‘).‘ WHERE itemid=\‘‘.$itemid.‘\‘ AND status=\‘‘.$status.‘\‘‘)

$itemid是有单引号保护的并且做了select查询,如果查询有结果才会带入到delete中,如果无结果就不执行delete。在数据库里itemid是int类型存储的,所以这里本意是只能提交数字型才能查询出结果,如果不是提交的数字的话那么就查询不出来结果,就不去执行下面的delete语句了。但是由于mysql的类型转换,因为这里储存的是int类型,所以1xxxxx跟1的查询结果是一样的,如下:

然后后面第二条delete的sql语句如下

$_SGLOBAL[‘db‘]->query(‘DELETE FROM ‘.tname(‘spacetags‘).‘ WHERE itemid=‘.$itemid.‘ AND tagid IN (‘.simplode($deletetagidarr).‘) AND status=\‘‘.$status.‘\‘‘);

这里忘记加单引号了,根据上图我们可以构造获取数据库用户的POC:

http://localhost/sup/dan/supesite/cp.php?ac=news&op=view&itemid=4 and 1=(updatexml(1,concat(0x5e24,(select user()),0x5e24),1))#

3.php弱类型语言,判断逻辑错误引发注入

还是雨牛的案例http://www.wooyun.org/bugs/wooyun-2010-088872
这里只讲下漏洞形成的原理

如上图,弱类型语言在逻辑判断上0<1和0 union select 1<1是等价的,都返回True。

数组类型,全局防护只过滤了value,key未过滤带入了查询

程序员往往在对数组的处理上不够严谨,导致会出现此类漏洞,笔者当年有幸挖到过ShopEx旗下的ecmall存在这类漏洞,链接:http://www.wooyun.org/bugs/wooyun-2010-065284
由于上面那个案例跟序列化相关且过程较为复杂,这里引用乌云另外一则案例:http://www.wooyun.org/bugs/wooyun-2010-069746,简要分析这个案例,我们首先看下对数组进行处理的函数:

$_POST=Add_S($_POST);$_GET=Add_S($_GET);$_COOKIE=Add_S($_COOKIE);... ...function Add_S($array){	foreach($array as $key=>$value){		if(!is_array($value)){			$value=str_replace("&#x","& # x",$value);	//过滤一些不安全字符			$value=preg_replace("/eval/i","eva l",$value);	//过滤不安全函数			!get_magic_quotes_gpc() && $value=addslashes($value);			$array[$key]=$value;		}else{			$array[$key]=Add_S($array[$key]); 		}	}	return $array;

可以看到对数组的value进行了严格的过滤和addlashes转义,但对key没有任何过滤操作,然后我们全局搜索关键词“$key=>$value”,发现如下代码$key被带入了查询

elseif($job==‘manage‘){	if(!$atc_power)showerr("你没权限");	if($rsdb[pages]<2){		header("location:post.php?job=edit&aid=$aid&mid=$mid&only=$only");exit;	}	$erp=get_id_table($aid);	if($step==2){		asort($orderDB);		$i=0;		foreach( $orderDB AS $key=>$value){			$i++;			$db->query("UPDATE {$pre}reply$erp SET orderid=$i WHERE aid=‘$aid‘ AND rid=‘$key‘");		}

构造获取管理员账户密码的POC如下图:

其它案例:http://www.wooyun.org/bugs/wooyun-2014-071516

SERVER变量未过滤

常常发生在获取用户ip并入库的函数上,类似如下代码:

//获取访问者IP(PHP代码/函数)	function get_ip(){	if(getenv("HTTP_CLIENT_IP") && strcasecmp(getenv("HTTP_CLIENT_IP"),"unknown")){	  $ip=getenv("HTTP_CLIENT_IP");	}else if (getenv("HTTP_X_FORWARDED_FOR") && strcasecmp(getenv("HTTP_X_FORWARDED_FOR"),"unknown")){	  $ip=getenv("HTTP_X_FORWARDED_FOR");	}else if (getenv("REMOTE_ADDR") && strcasecmp(getenv("REMOTE_ADDR"),"unknown")){	  $ip=getenv("REMOTE_ADDR");	}else if (isset($_SERVER[‘REMOTE_ADDR‘]) && $_SERVER[‘REMOTE_ADDR‘] && strcasecmp($_SERVER[‘REMOTE_ADDR‘],"unknown")){	  $ip=$_SERVER[‘REMOTE_ADDR‘];	}else{	  $ip="unknown" ;  	}	return $ip;  }

发现通过$_SERVER变量获取客户端ip且可以通过X_FORWARDED_FOR伪造,然后这里对X_FORWARDED_FOR是没有任何正则处理的,所以我们全局搜索下get_ip函数发现有一些调用并且入库的地方。
program/index/receive/login.php处代码为例:

//这里使用get_ip函数获取客户ip$ip=get_ip();//这里入库,所以可以注入了$sql="update ".$pdo->index_pre."user set `last_time`=‘$time‘,`last_ip`=‘$ip‘ where `id`=‘".$_SESSION[‘monxin‘][‘id‘]."‘";$pdo->exec($sql);$sql="select count(id) as c from ".$pdo->index_pre."user_login where `userid`=‘".$_SESSION[‘monxin‘][‘id‘]."‘";$stmt=$pdo->query($sql,2);$v=$stmt->fetch(2);if($v[‘c‘]<self::$config[‘other‘][‘user_login_log‘]){	$sql="insert into ".$pdo->index_pre."user_login (`userid`,`ip`,`time`,`position`) values (‘".$_SESSION[‘monxin‘][‘id‘]."‘,‘$ip‘,‘$time‘,‘".get_ip_position($ip)."‘)";}else{	$sql="select `id` from ".$pdo->index_pre."user_login where `userid`=‘".$_SESSION[‘monxin‘][‘id‘]."‘ order by time asc limit 0,1";	$stmt=$pdo->query($sql,2);	$v=$stmt->fetch(2);	$sql="update ".$pdo->index_pre."user_login set `ip`=‘$ip‘,`time`=‘$time‘ where `id`=‘".$v[‘id‘]."‘";}$pdo->exec($sql);

案例:http://www.wooyun.org/bugs/wooyun-2010-0173485

原文链接:http://www.cnbraid.com/2016/05/10/sql6/,如需转载请联系作者。

时间: 2024-08-12 09:01:52

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

【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注入 - 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注入 - 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注入 - 4.全局防护Bypass之二次注入

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

那些年我们一起挖掘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注入 - 6.全局防护Bypass之一些函数的错误使用

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

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

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

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

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

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

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