ThinkPHP之SQLI审计分析(三)

该文章来源于徒弟lu2ker转载至此处&＃xff0c;更多文章可参考&＃xff1a;https://github.com/lu2ker/

影响版本&＃xff1a;ThinkPHP&＃61;5.1.22

Payload&＃xff1a;

/public/index.php/index/index?orderby[id&＃96;|updatexml(1,concat(0x7,user(),0x7e),1)%23]&＃61;1


这是一篇由已知漏洞寻找利用过程的文章&＃xff0c;跟着**参考链接**学习分析。以下是收获记录。

感谢七月火的高质量文章。

0x00 测试代码做了什么


namespace app\index\controller;
class Index
{
public function index()
{
$orderby &＃61; request()->get(&＃39;orderby&＃39;);
$result &＃61; db(&＃39;users&＃39;)->where([&＃39;username&＃39; &＃61;> &＃39;mochazz&＃39;])->order($orderby)->find();
var_dump($result);
}
}


以GET方式从orderby中获取参数值&＃xff0c;查询users表中username&＃61;mochazz&＃xff0c;再用order方法添加排序语句最后find获取结果。

request类是在thinkphp/library/think/Request.php中定义的&＃xff0c;其get方法&＃xff1a;

并没有什么比较关键的东西&＃xff0c;之前在研究&＃xff08;username/a&＃xff09;的a是什么意思时&＃xff0c;对get到input方法的调用处理流程也分析过&＃xff0c;最终的过滤代码是在thinkphp/library/think/Request.php的1408行的filterValue函数&＃xff0c;但是由于仅仅是一个框架&＃xff0c;并没有添加自定义的过滤器进行过滤。所以这边基本上是传入什么值就获取什么值。未来如果没有特殊情况就不用分析测试代码的作用了。

0x01 分析调用链

• where()方法

emm&＃xff0c;这个版本的parseWhereExp方法与之前分析过的5.0.10版本的不太一样&＃xff0c;所以还是学习一下吧。

1474-1477行像是修了个小BUG的样子&＃xff0c;之所以会这么想是因为getOptions方法是这么写的&＃xff1a;

总的来说感觉大概是防止为空时出错吧。不重要。

但有了5.0.10版本分析的经验&＃xff0c;知道parseWhereExp方法中主要看的是if-else语句块。这段代码如下&＃xff1a;

因为$field是一个数组&＃xff08;$field就是测试代码中where中的参数值&＃xff09;所以直接跳到1495行看起&＃xff0c;进入parseArrayWhereItems方法。并且&＃xff0c;在parseArrayWhereItems处理完后就会直接return了。

1564行if条件满足&＃xff0c;foreach拆分username和mochazz&＃xff0c;之后会进入1571行的else中对$where数组进行赋值&＃xff0c;这里三元运算因为mochazz不是数组&＃xff0c;所以第二个元素最终为’&＃61;&＃39;&＃xff0c;然后到1580行的if&＃xff0c;也是简单的取值赋值操作。

where方法分析完毕&＃xff0c;好像也没什么不同。区别在于5.0.10中没有看parseArrayWhereItems方法&＃xff0c;这次补上了。下断点看一下处理后的最终结果&＃xff1a;

• order()方法&＃xff0c;本次的主角

thinkphp/library/think/db/Query.php的1823-1864行&＃xff0c;因为测试代码给定参数的特殊性&＃xff0c;程序不会进入部分代码&＃xff0c;也为了舍去不必要的篇幅&＃xff0c;直接来到1853行开始看起&＃xff1a;

1854行&＃xff0c;既然where在options中是个数组&＃xff0c;那么order在options也应是个数组&＃xff0c;很合理。

1857行&＃xff0c;判断为数组&＃xff0c;之后也是用array_merge进行简单的赋值操作。还是下断点看看执行完的情况&＃xff1a;

自始至终没有任何有效的过滤存在意味着where和order值都是可控的。但是具体怎么触发漏洞还是没有个清晰的逻辑&＃xff0c;往后看find的执行流程吧。

。。。

实际上&＃xff0c;也没什么看头&＃xff0c;基本上是在解析$this->options中的值&＃xff0c;然后在3041行调用另一处的find方法&＃xff0c;而后执行的代码与前几次分析SQLI漏洞的流程基本一致。em先下个断点看一下SQL语句构造完成后是什么&＃xff1a;
最终在thinkphp/library/think/db/Connection.php中find方法的826行生成的SQL语句。

明显可以看到是通过反引号闭合id前一个反引号导致的注入攻击。

既然是order by之后的注入&＃xff0c;那么漏洞点一定和select方法中调用的parseOrder这个方法有关系&＃xff1a;

有了以往的经验&＃xff0c;知道具体代码都在thinkphp/library/think/db/Builder.php中&＃xff0c;来到847行的parseOrder

阅读855-871行&＃xff0c;暂时不看程序不会进入的代码直接来到最后一个else&＃xff0c;863-869都没有什么特殊的地方&＃xff0c;870会把$sort置为空&＃xff0c;871行的parseKey方法很关键&＃xff0c;跟进。

它的作用是获取key的值。但是下断点步进发现&＃xff0c;调用的实际上不是Builder.php中的parseKey而是Mysql.php中的parseKey&＃xff0c;是因为自始至终Mysql都是extends于Builder的&＃xff0c;前面一直在Builder中分析代码是因为Mysql中没有写相应的函数&＃xff0c;自然就向父类查找了&＃xff0c;但是与以往不同的是&＃xff0c;parseKey是在Mysql中定义好的。&＃xff08;涨记性&＃xff0c;有经验了也得根据实际情况来。&＃xff09;

来到实际执行的parseKey&＃xff1a;

thinkphp/library/think/db/builder/Mysql.php的113行&＃xff1a;

已知的payload并不满足123行的if&＃xff0c;直接会到143行处的if&＃xff0c;因为$strict是写死的true&＃xff0c;这个if必然会进入&＃xff0c;然后执行的操作是往$key的两边直接拼接加反引号&＃xff0c;这个时候想到payload的形式&＃xff0c;毫无疑问漏洞点就在这里。

最后&＃xff0c;将return的$key拼接上$sort&＃xff0c;再在parseOrder中的875行拼接前缀ORDER BY&＃xff0c;SQL注入就构造好了。

0x03 总结

这次分析并没有那么细&＃xff0c;也没有想太多&＃xff0c;只是根据payload和测试代码的流程过了一遍。并不是严格意义上的白盒审计&＃xff0c;很多程序没有进入的代码并没有认真去分析&＃xff0c;不知道其他代码做了什么就很可能还存在漏洞点。还是一样的感觉&＃xff1a;目前所学习的代码审计就是一个跳过某段代码和进入某段代码的过程&＃xff0c;也就是所谓的“链”。至于绕过过滤这些&＃xff0c;感觉不是代码审计的重点&＃xff0c;只能算是一种奇巧的思路吧。

加油。