PDO(预编译参数化查询)和安全问题

Posted wangtanzhi

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了PDO(预编译参数化查询)和安全问题相关的知识,希望对你有一定的参考价值。

前言

在看梅子酒师傅的一篇文章中:

https://meizjm3i.github.io/2018/04/04/对PHP类CMS审计的一点总结/
看到了对SQL注入的挖掘思路:
cms中如果使用了PDO,我们的挖掘思路就是跟进涉及到table,order by等字段的拼接去,因为这些字段是无法使用PDO的。为什么无法使用?这篇文章来分析一下。

什么是PDO

毫无疑问,他的无法使用和PDO有关。我们先来了解一下PDO。

PDO(php Data Object),PHP数据对象,它提供了一个轻量级的接口,使得我们不管使用哪种数据库,都可以用相同的函数(方法)来查询和获取数据,同时,它的预编译机制可以用来防止SQL注入。PDO有两种模式:本地预处理和模拟预处理。

我们先来看一下模拟预处理。
因为默认情况下就是使用的模拟预处理。会有什么问题?
我们先看代码:
比如以下代码:

stmt=PDO -> prepare("SELECT * FROM userWHERE id = ?");
stmt -> bindParam(1,stmt?>bindParam(1‘,_GET[‘id‘]);
$stmt -> execute();

这个就是PDO处理的三个步骤,不再解释。重点关注我们第二步绑定参数的时候是1‘
这个执行结果其实可以这样拆分:

Connect    root@localhoston nowcoder
Query    SELECT * FROM user WHERE id = ‘1‘‘
Quit

我们看到这里有个问题,他这里整个SQL语句由PHP处理并转义,然后交由mysql处理。也就是说整个过程只有连接、查询、退出三个操作,并没有预编译的过程。他在经过
PreparedStatement处理后(PreparedStatement能防止注入,是因为它把单引号转义了,变成了‘),然后直接拼接执行。
总结:模拟预处理用于数据库不支持预编译机制的情况,其本质是在底层先对用户输入进行转义后,再对SQL语句进行拼接,然后将完整的语句发送给数据库执行。任何可控的拼接都是具有一定危险性的,在PHP 5.3.6前,这种转义是通过单字节字符集来完成的,因此存在宽字节注入。但在正确设置字符集的前提下,不可否认这种方式是可以防止SQL注入的。

我们再来看一下本地预处理模式即使用了真正的数据库预编译。
先上网上被写烂的一句话:

预编译防止注入的原因:

关于预编译能够防止注入的原因,还要从预编译的运行机制说起。通常来说,在MySQL中,一条SQL语句从传入到执行经历了以下过程:检查缓存、规则验证、解析器解析为语法树、预处理器进一步验证语法树、优化SQL、生成执行计划、执行。

预编译使用占位符?代替字段值的部分,将SQL语句先交由数据库预处理,构建语法树,再传入真正的字段值多次执行,省却了重复解析和优化相同语法树的时间,提升了SQL执行的效率。

正因为在传入字段值之前,语法树已经构建完成,因此无论传入任何字段值,都无法再更改语法树的结构。至此,任何传入的值都只会被当做值来看待,不会再出现非预期的查询,这便是预编译能够防止SQL注入的根本原因。
说了这么一段话,怎么概况呢?这里本菜来说下自己的理解:

网上对PDO防注入的回答大多都停留在预编译会将传入的数据只当做数据,却没解释为什么会当成数据。事实上这个数据并不需要识别。
也就是说我们比如执行:

select * from user where username=‘admin‘

使用PDO后他会生成

select * from user where username=‘?‘

请注意这个语句无法再改变,我们可以理解为他只能执行这个语句。
那么我们的数据比如admin或者admin‘ union select * fromxx
这种他会不做操作直接拼接到占位符位置处。
这样保证了我们的sql语句原有的查询不会被改变。

安全问题

在了解了PDO后,我们来说下我们今天讨论的东西:

table,order by等字段无法使用PDO,为什么?
这里以order by为例:
这里我以最简单的来说明:

order by是mysql中对查询数据进行排序的方法, 使用示例

select * from 表名 order by 列名(或者数字) asc;升序(默认升序)
select * from 表名 order by 列名(或者数字) desc;降序
select * from user order by id; 
selecr * from user order by 1;

结合union来盲注:

 $sql = ‘select * from admin where username=‘".$username."‘‘;
$result = mysql_query($sql);
$row = mysql_fetch_array($result);
if(isset($row)&&row[‘username‘]!="admin"){
	$hit="username error!";
}else{
	if ($row[‘password‘] === $password){
		$hit="";
	}else{
		$hit="password error!";
	}
             
}

payload

username=admin‘ union 1,2,‘字符串‘ order by 3

这里就会对第三列进行比较,即将字符串和密码进行比较。然后就可以根据页面返回的不同情况进行盲注。 注意的是最好加上binary,因为order by比较的时候不区分大小写。
技术图片

这里的order by 3是根据第三列进行排序,如果我们union查询的字符串比password小的话,我们构造的 1,2,a就会成为第一列,那么在源码对用户名做对比的时候,就会返回username error!,如果union查询的字符串比password大,那么正确的数据就会是第一列,那么页面就会返回password error!.

这里就来说一下我们上面的payload:
我们想要爆破密码,那么我们可以轮流带入查询来观察排序情况,那么之后一定能注入出密码。
在说以下PDO特性:

表名和列名是不能够被预编译的,这是由于生成语法树的过程中,预处理器在进一步检查解析后的语法树时,会检查数据表和数据列是否存在,因此数据表和数据列不能被占位符?所替代。这个就很好理解,我们如果传入一个表名他会先检查在该查询语句中是否存在,不存在则报错。但在很多业务场景中,表名需要作为一个变量存在,因此这部分仍需由加号进行SQL语句的拼接,若表名是由外部传入且可控的,仍会造成SQL注入。
所以:
ORDER BY后的ASC/DESC也不能被预编译,因为在使用PDO后查询时不能识别会报错。当业务场景涉及到用户可控制排序方式,且ASC/DESC是由前台传入并拼接到SQL语句上时,就可能出现危险了
技术图片

在上面进行查询时我没有写ASC,因为他默认就是ASC,我们也可以改变:
技术图片

我们可以设想一下,假如order by后面有拼接,ASC/DESC没有做严格检查后,就会导致注入。
order by注入的防范的话直接做个intval强制类型转换,其他的更有效的还没想到。。

参考

https://meizjm3i.github.io/2018/04/04/对PHP类CMS审计的一点总结/

https://cloud.tencent.com/developer/news/378220

以上是关于PDO(预编译参数化查询)和安全问题的主要内容,如果未能解决你的问题,请参考以下文章

PDO预编译语句执行查询与DML操作

SQL预编译中order by后为什么不能参数化原因

使用 PDO 准备参数化查询

PDO 参数化查询的工作方式

参数化 PDO 查询和“LIMIT”子句 - 不起作用 [重复]

web安全SQL注入中order by后无法参数化