ThinkPHP 3.2.3及部分5.x早期版本存在多处SQL注入漏洞：where()数组中exp键绕过过滤、table/alias参数直拼、ORDER BY字段未校验、find()数组参数跳过主键检查。
where() 方法传入数组时的 exp 键绕过校验
ThinkPHP 3.2.3 和部分 5.x 早期版本中，where() 接收数组参数时，若键名为 exp，会直接取其第二元素（$val[1]）拼入 SQL，不经过任何过滤。这是最常被利用的注入入口。
常见错误现象：页面返回 MySQL 报错，如 MySQL syntax error near '...' 或 Unknown column 'xxx' in 'field list'，说明恶意 SQL 已进入执行阶段。
- 典型触发路径：
Model::where(['id' => ['exp', "1=1) AND (SELECT 1 FROM (SELECT COUNT(*), CONCAT(0x3a,(SELECT DATABASE()),0x3a,FLOOR(RAND(0)*2)) x FROM INFORMATION_SCHEMA.PLUGINS GROUP BY x) y)"]) - 注意
exp必须是数组第一项，第二项才是可执行 SQL；大小写敏感，EXP不生效（除非框架启用了忽略大小写的正则） - ThinkPHP 5.0.24 中
wp_where()函数存在同样逻辑，但位于application/common.php，不是框架原生方法，属于项目层误用
table() 和 alias() 参数未过滤导致 UNION 注入
table() 和 alias() 在 ThinkPHP 3.2.3 的 _parseOptions() 中完全放行字符串，攻击者可直接注入 UNION SELECT 片段，且绕过所有 bind 参数机制。
使用场景：商品列表、用户管理等需动态指定表名或别名的功能模块，尤其是后台接口暴露了 table 或 alias 参数。
立即学习“PHP免费学习笔记（深入）”；
- 示例 payload：
http://target.com/index.php?s=/product/list&table=tp_user%20UNION%20SELECT%201,2,@@version,4--+ - 关键点：
table值在buildSelectSql()中被str_replace('%TABLE%', $table, $sql)直接替换，无任何parseKey()或转义 - ThinkPHP 5.x 默认禁用该用法，但若项目手动调用
Db::table($user_input)，仍会复现相同问题
ORDER BY 子句拼接未校验排序字段
CRMEB 等基于 ThinkPHP 的项目中，get_list() 类方法常将用户传入的 order 参数直接拼进 SQL 的 ORDER BY 位置，导致布尔/报错注入。
性能影响小但危害高：该漏洞无需登录、不依赖错误回显，配合时间盲注（SLEEP()）仍可稳定读库。
- 典型代码：
$order = input('order', 'id desc'); $list = Db::name('product')->order($order)->select(); - 危险参数值：
id,updatexml(1,concat(0x7e,(SELECT user())),0)（报错注入） - 容易踩的坑：开发者以为
input()自带过滤，但 ThinkPHP 的input()默认只做 trim 和类型转换，不校验字段白名单
Model::find() 传入数组跳过主键检查
ThinkPHP 3.2.3 的 Model::find($options) 对数组参数处理存在逻辑缺陷：当 $options 是数组时，直接进入 _parseOptions()，跳过单主键类型校验，使 table、where、limit 等全量可控。
兼容性影响明显：该问题在 3.2.3 全版本存在，但 ThinkPHP 5.1+ 引入了 allowField 和严格模式后大幅缓解。
- 复现条件：目标表为单主键（如
id），且控制器未对input('id')做intval()强制转换 - payload 示例：
['table' => 'tp_user WHERE 1=1 UNION SELECT 1,2,3-- ', 'limit' => 1] - 最容易被忽略的一点：即使开启了
debug = false，SQL 语句仍会构造并执行，只是错误不回显——必须靠盲注或日志侧信道确认
