PHP代码审计 -1.SQL注入总结

最新推荐文章于 2025-04-19 18:23:24 发布

转载最新推荐文章于 2025-04-19 18:23:24 发布 · 110 阅读

0 ·

CC 4.0 BY-SA版权

原文链接：http://www.cnblogs.com/xiaozi/p/5538921.html

0x01 背景

最近在学习PHP代码审计，这里做一个SQL注入总结，是对自己学习知识的总结，也是为自己学习的笔记，方便自己反复翻阅。

0x02 PHP代码审计-SQL注入

挖掘SQL注入漏洞的时候，最简单也最容易被发现的就是什么都没过滤的情况。

代码示例

<?php $id = $_REQUEST[ 'id' ]; //接收参数
$query = "SELECT first_name, last_name FROM users WHERE user_id = '$id';"; //sql语句拼接 $result = mysql_query( $query ) ; //带入数据库执行
?>

什么都没过滤的情况下，我们只需按照参数拼接的位置去构造POC，参数位置可能在select/insert/update/delete或者order by/group by /having/limit等关键字之后，这需要我们对sql注入有一个比较清晰的认知，方能快速构造POC。

0x03 绕过全局防护

现在的WEB程序基本都有对SQL注入的全局过滤，像PHP开启了GPC或者在全局文件common.php上使用addslashes()函数对接收的参数进行过滤，尤其是单引号。遇到这种情况我们就需要找一些编码解码的函数来绕过全局防护。

情况一：urldecode()

' url编码是%27

% url编码是%25

%2527 ---服务器接收参数进行还原---%27--urldecode解码--单引号

%252527---urldecode解码--%2527--urldecode解码---%27（单引号）

<?php
    $id= mysql_real_escape_string($_GET[ 'id' ]); //模拟全局过滤
    echo $id;
    echo "<br />";
    $id=urldecode($id); //模拟url解码
    echo $id;
  $query = "SELECT first_name, last_name FROM users WHERE user_id = '$id';"; //sql语句拼接 $result = mysql_query( $query ) ;
?>

通过%2527绕过单引号的过滤，然后通过url解码为%27，从而绕过单引号的过滤，带入到数据库操作，造成sql注入。

情况二： base64_decode()

通过base64_decode解码，从而绕过单引号的过滤，把单引号带入数据库。

代码示例如下：

<?php
    $id= mysql_real_escape_string($_GET[ 'id' ]); //模拟全局过滤
    echo $id;
    echo "<br />";
    $id=base64_decode($id); //模拟base64_decode解码
    echo $id;
    echo "<br />";
    $query = "SELECT first_name, last_name FROM users WHERE user_id = '$id';";      $result = mysql_query( $query ) ;
?>

情况三：宽字节注入

宽字节注入，宽字节注入源于程序员设置MySQL连接时错误配置为：set character_set_client=gbk，这样配置会引发编码转换从而导致的注入漏洞。具体原理如下： 1.正常情况下当GPC开启或使用addslashes函数过滤GET或POST提交的参数时，黑客使用的单引号 ‘ 就会被转义为: \’； 2.但如果存在宽字节注入，我们输入%df%27时首先经过上面提到的单引号转义变成了%df%5c%27（%5c是反斜杠\），之后在数据库查询前由于使用了GBK多字节编码，即在汉字编码范围内两个字节会被编码为一个汉字。然后MySQL服务器会对查询语句进行GBK编码即%df%5c转换成了汉字“運”（注：GBK的汉字编码范围见附录），而单引号逃逸了出来，从而造成了注入漏洞。现在基本上都会将mysql的连接配置为“set character_set_client=binary”来解决这个问题。

输入-- 錦’，“錦”这个字，它的utf-8编码是e98ca6，它的gbk编码是e55c，而上面提到过反斜杠\正好为5c，首先经过addlashes函数或GPC对单引号转义变为：錦\’，然后这里注册时会经过icnov函数会对”錦”转化为gbk编码，最后就是：％e5％5c％5c％27。反斜杠被转义了（％5c％5c），从而单引号逃逸出来引发注入漏洞。

POC:

%E9%8C%A6%27%20union%20select%201,2,3,user(),5,6,7,database(),9%23

因为# %0a的一些闭合都被过滤了,可以使用-<a>- a会在浏览器执行为-- a这样就闭合了

情况四：二次注入

二次注入也是一种比较常见的注入，它涉及到入库和出库。因为有全局转义所以入库的时候：

Insert into table (username) values (‘hack\’’); 这样入库后转义符就会消失变成了hack’，这样如果hack’出库被带入查询的话就会成功的引入了单引号导致注入。

0x04 可能存在的注入点

1、注入点类似id=1这种整型的参数就会完全无视GPC的过滤；

2、注入点包含键值对的，那么这里只检测了value，对key的过滤就没有防护；

3、有时候全局的过滤只过滤掉GET、POST和COOKIE，但是没过滤SERVER。附常见的SERVER变量（具体含义自行百度）：QUERY_STRING,X_FORWARDED_FOR,CLIENT_IP,HTTP_HOST,ACCEPT_LANGUAGE

4、FILES注入，全局只转义掉GET、POST等传来的参数，遗漏了FILES；

5、变量覆盖，危险函数：extract()、parse_str()、$$。