thinkphp3.2.3框架SQL注入漏洞分析

前言

本文主要针对thinkphp框架漏洞sql注入的分析，环境搭建部分没有写。环境搭建可以参考这位师傅的博客

普通payload调试

find函数里有猫腻，后面我们就看看find函数的逻辑是怎么处理的。

option先是进_parseOptions处理，在其中又进_parseType这里定义了一个fieldType为bigint(20)。

感觉这样没啥就是来来回回定义了几个变量

往后跟进，得进这一个_options_filter对options进行处理

慢慢继续跟进到了$resultSet = $this->db->select($options);看到select函数，应该就是查询函数了。

进入select这里又是一个buildSelectSql，继续进入。

进到buildSelectSql，没有满足if的条件，又要进parseSql。

进parseSql，发现做了一些替换。我们的参数是where，所以我们着重看看parseWhere干了啥

其余的这几个parse会赋一些变量值，很常规对注入影响不大，直接略过。初始传入的where是user_id = "1'"。后面就是把where的数组值拆分成$key和$val。后面我们主要关注$key和$val的变化

跟进，对$key加了个反引号。

这里是要对$val做处理了，我们跟进parseValue

OK在这里发现了会转义，咱们的1'被转换为了"'1\''"这样就不会导致数据库报错了。防住了测试的payload。

漏洞payload调试

payload：user_id[where]=1'

进到find，这样传options应该长这样

这回两个if都不满足，后面getPK()和$options['limit'] = 1后直接走到_parseOptions()

进到_parseOptions()，options的值如下where为"1'"。

还是在_parseOptions()中，这个where是字符串，进不到这个if里

后面跟之前一样的流程，进到parseWhere。嘻嘻，发现这次进到前面的if (is_string($where))，而不是刚刚的else里面。这里没做转义就返回了$whereStr

OK，这样我们就构造出来带报错的payload了，回浏览器看一下。

果然爆出查询语句，后面就是常规的sql注入了