ThinkPHP5 SQL注入漏洞 && PDO真/伪预处理分析
刚才先知分享了一个漏洞（ https://xianzhi.aliyun.com/forum/read/1813.html ），文中说到这是一个信息泄露漏洞，但经过我的分析，除了泄露信息以外，这里其实是一个（鸡肋）SQL注入漏洞，似乎是一个不允许子查询的SQL注入点。
漏洞上下文如下：
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操作代码如下：
$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语句的话，那么在第二步的时候是会抛出错误的：
刚才先知分享了一个漏洞（ https://xianzhi.aliyun.com/forum/read/1813.html ），文中说到这是一个信息泄露漏洞，但经过我的分析，除了泄露信息以外，这里其实是一个（鸡肋）SQL注入漏洞，似乎是一个不允许子查询的SQL注入点。
漏洞上下文如下：
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操作代码如下：
$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语句的话，那么在第二步的时候是会抛出错误的：