复现
先搭建thinkphp5.0.9环境
配置下测试环境
然后访问
http://tptest.cc/index.php/index/index/getage?names[0,updatexml(0,concat(0xa,user()),0)]=1
复现成功
【点击获取学习资料】
渗透工具
技术文档、书籍 最新大厂面试题目及答案
视频教程
应急响应笔记
学习思路构图等等
漏洞分析
先看看传进来了什么
是一个关联数组
跟进where
跟进parseWhereExp，看了一番，就是普通的对where参数解析
继续跟进select
Query的select函数从这里开始，构造的sql语句就出问题了
继续跟进builder->select -> parseWhere -> buildWhere -> parseWhereItem
在这里将关联数组的key拼接了上去
正常查询，传参names[]=li，构造出来的应该是这样
生成的预处理sql应该是这样，where_name_in_0会被替换为li
而恶意payload，生成的是
看一下最终生成的sql语句
调试发现，预处理发生了错误，但是报错注入成功，语句被执行了？预处理时执行了sql语句？
想调试下，但是这条语句，进不去，不能调试，，不知道什么原因，
$this->PDOStatement = $this->linkID->prepare($sql);
在网上看到了p神的文章
https://www.leavesongs.com/PENETRATION/thinkphp5-in-sqlinjection.html
就是说在PDO::ATTR_EMULATE_PREPARES => false模式下，预处理是假的，边替换边执行，这就可以解决
释得通了
找一下不能仔细查询的原因
构造payload：
?names[0,updatexml(0,concat(0xa,(select group_concat(SCHEMA_NAME) from information_schema.SCHEMATA )),0)]=1
预处理没有报错
但在$result = $this->PDOStatement->bindValue($param, $val[0], $val[1]);时报错
应该是PDO的预处理，不能解析这一长串
那就从param入手看一下，
param来自$bind
$bind来自上面遇到过的
想绕过就要让$bindKey变为where_name_in_0，，但是构造的sql语句不变，做不到，立刻放弃
令我疑惑的两个点
user()查询是在预处理时报错退出的，子查询是在绑定key-value时退出的
而且使用子查询，PDO是解析成功了的，在mysql日志看到如下
使用user()查询日志：
直接用sql语句查日志
为什么PDO调用user()，在mysql日志看不到记录
搞不懂
总结
thinkphp没有对输入过滤，直接做拼接
众所周知预处理不能处理in，order by这些动态的变量，所以审计的时候可以重点看一下
这个漏洞没什么用，不过可以当个练习了
造成这个漏洞的原因一是thinkphp没有对输入进行过滤，直接将输入拼接。二是由于PDO的特性，在预处理时把代码执行了
如何修复
看5.0.22，已经修复
select生成的语句没有我们构造的内容了
继续调试，bindkey后面不使用key拼接了，而是使用递增的i
这是5.0.9的
