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

0x01 背景

PHP程序员在开发过程中难免会使用一些字符替换函数(str_replace)、反转义函数(stripslashes),但这些函数使用位置不当就会绕过全局的防护造成SQL注入漏洞。

0x03 漏洞分析

str_replace函数的错误使用

第一种情况是写程序时会使用str_replace函数将参数中的单引号、括号等字符替换为空,这样在一些双条件查询的情况就会引发注入问题。缺陷代码如下:

<?phprequire_once(‘common.php‘);$conn = mysql_connect(‘localhost‘, ‘root‘, ‘braid‘) or die(‘bad!‘);mysql_query("SET NAMES binary‘");mysql_select_db(‘test‘, $conn) OR emMsg("数据库连接失败");$tmp_id = isset($_GET[‘id‘]) ? $_GET[‘id‘] : 1;$title = isset($_GET[‘title‘]) ? $_GET[‘title‘] : ‘news title‘;//程序编写时直接用str_replace去掉id里的单引号$id = str_replace("‘",‘‘,$tmp_id);//sql查询语句通过id和titile两个条件进行查询$sql = "SELECT * FROM news WHERE id=‘{$id}‘ and title=‘{$title}‘";echo $sql;$result = mysql_query($sql, $conn) or die(mysql_error()); ?>

浏览器输入”http://localhost/sqltest/streplace.php?id=1‘&title=news title”,发现报错了,我们直接打印出执行的sql语句如下图:

发现参数id右边的单引号被反斜杠转义成字符了,说明又可以注入了。
简单分析下上面id参数的执行过程,-1’经过addslashes函数转义后变成了-1\’,然后再经过str_replace函数干掉了单引号变成了-1\,最后带入查询的语句才是下面这样:

SELECT * FROM news WHERE id=‘1\‘ and title=‘news title‘

反斜杠转义了sql查询语句里id后面那个单引号,导致title参数可以构造sql注入语句了,我们直接构造获取管理员账户密码的语句”http://localhost/sqltest/streplace.php?id=-1‘&title=unionselect 1,2,concat(name,0x23,pass) from admin%23”

第二种情况是str_replace函数是用户可控的,就是说用户想把啥替换成空就可以将什么替换为空。
首先我们先看看addslashes函数对%00-%ff的转义情况,经过fuzz发现%00会被转义为\0,如下:

那么注入的时候我们提交%00’,经过addlashes就会变为\0\’,这时候我们用replace函数替换0为空就变成了\‘,成功转义了转义字符让单引号逃逸出来,从而造成注入漏洞。

stripslashes函数的错误使用

这个函数的定义是删除由 addslashes() 函数添加的反斜杠,所以很明显使用不当的话就会引发SQL注入。缺陷代码如下:

<?phprequire_once(‘common.php‘);$conn = mysql_connect(‘localhost‘, ‘root‘, ‘braid‘) or die(‘bad!‘);mysql_query("SET NAMES binary‘");mysql_select_db(‘test‘, $conn) OR emMsg("数据库连接失败");$tmp_id = isset($_GET[‘id‘]) ? $_GET[‘id‘] : 1;$id = stripslashes($tmp_id);$sql = "SELECT * FROM news WHERE id=‘{$id}‘";echo $sql.‘<br />‘;$result = mysql_query($sql, $conn) or die(mysql_error()); ?>

浏览器输入”http://localhost/sqltest/stripslashes.php?id=-1‘",发现报错了,echo出执行的sql语句如下图:

分析下参数id的执行过程,-1’经过addslashes函数转义后变成了-1\’,然后再经过stripslashes函数干掉了反斜杠变成了-1’,所以又可以愉快的注入了。
获取管理员账户密码的语句”http://localhost/sqltest/stripslashes.php?id=-1‘ union select 1,2,concat(name,0x23,pass) from admin%23”

原文链接:http://www.cnbraid.com/2016/04/29/sql5/,如需转载请联系作者。

时间: 2024-07-29 21:14:49

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

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

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

【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注入 - 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多

【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