“Mysql代码审计系统”的SQL语句到mysql.general_log

因为新冠病毒的席卷造成相关地区疫情严重，挑动着全省人民的心。作为普通人，我们似乎难以直接去增援她们，而且我们依然可以给社会尽一份力：注意卫生防护不集聚，疑似重病即隔离，不信谣不造谣等。先森不懂医学也难以去增援疫情地区，只能祈求一切安好、呆在家不给国家和稀泥。在这显然遥遥无期、基本绝缘的日子里，看新闻联播、学习和傻笑，这也让我深深地感受到拥抱自由、遵守法律的重要意义……

引子：钻研技术，发觉问题

ThinkPHP框架是国外知名的PHP开源框架，因其灵活和功能强悍拥有诸多用户。老话说树大招风，前几年修补了若干严重的漏洞mysql数据库的本地文件，如远程代码执行(RCE)、本地文件包含(LFI)和SQL注入等等。先森仍然在ThinkPHP框架的旁边观望，没有系统地学习过，于是准备这种天好好补补这方面。

这不正好学到SQL操作的章节，以此可以好好研究TP框架的SQL注入与防御。于是写了一个简单的SQL句子，尝试调试查看TP底层最终处理后的句子，其实TP框架也外置了功能，如在tpconfigapp.php里开启”app_debug”和”app_trace”选项实现应用调试及追踪、在tpconfigdatabase.php里开启”debug”选项实现记录SQL操作等。

光那些还不够，为了更简便操作，起码还要配合MySQL句子监控工具等。这儿我习惯使用“Seay代码审计系统”的“Mysql监控”插件，它可以记录MySQL上用户执行的所有SQL操作，该工具原理是基于数据库中的general_log功能，将监控到的SQL句子转存到mysql.general_log表中之后再按需筛选下来。

这儿我写了一个特别简单的demo，该脚本的功能是通过查询指定id来返回用户的所有信息，TP底层最终执行的句子应当是”select*fromthink_userwhereid=xxx”。

在浏览器里按TP框架的访问方法，依次填入指定的模块、控制器、方法和参数访问后，浏览器按预定看法回显了我们数据，框架外置的调试器也显示执行了两条查询，而且我的“神器”却无任何有意义的回显。

于是我惊讶地挪到MySQL的管理工具里执行这个查询操作，此次确实可以监控到执行的SQL句子，所以排除了该工具存在故障的可能性。这就有些颠覆了我对MySQL数据库和ThinkPHP框架的认知，要晓得MySQL中general_log功能的作用就是记录用户的所有操作，堂堂一个Oracle公司不可能出这些问题吧？！

于是找到几位搞技术的同事讨教一下这个情况，她们对此也倍感奇怪。但疏于工作和其他事情，无瑕研究这个问题…俗话说自己动手丰衣足食mysql数据库的本地文件，加之对逆向工程越来越有浓烈兴趣了(旁边会有对工具的逆向过程)，便开始了这场刨根问底的行动。

索性将TP框架中的增删改查的方式都试了一遍，连同事提及的TP两种的原生执行SQL的方式也是这样，发觉真的都不行。

我简单的溯源了下TP底层是怎样处理数据库操作。从query函数出发->经由核心功能thinkQuery.php中的query方式->经由核心功能thinkCollection.php中的query方式，发觉最终是被PDO的prepare方式处理，简而言之就是经由SQL预处理了。所以问题是不是可能出在预处理上了？

为了更好的验证这个猜想，我写了一个mysqli下的预处理查询脚本，功能是查询think_user表中id为3的用户信息。通过浏览器的回显可以认定这三种查询方法是完全没问题的，而且Mysql监控工具的回显结果却不尽人意。所以综上，我们可以推断出是SQL编译预处理环节的问题。

未完待续……