这一漏洞原本是二零一四年那时候被别人发觉的，本着学习的了解，我来做一个具体的深入分析。漏洞尽管很早以前了，新版本的Drupal乃至早已更改了架构的查看形式。可是分毫不干扰针对漏洞的深入分析。这是一个经典的应用PDO，可是使用不当，造成SQL语句拼凑拼凑造成注入的问题。从这个问题，及其过去我见过的许多的漏洞来说，我不得不承认，源代码最底层做的再安全，过虑的再完全，要是软件工程师的1个不慎，也可能造成巨大安全隐患的形成。有多少的编写代码绕过，逻辑漏洞恰好是不慎形成的问题。

0x00注入的快速

最先我依据互联网上早已形成过的EXP，随后开展跟踪。无可奈何，这一架构真是太大，我还在跟进的环节中，碰到了众多的问题，乃至路由模式也没有搞的很清楚。随后依据现有的漏洞关键点，我快速快速到了漏洞的形成点。

在代码\modules\system\system.test中有system_user_authenticate_validate()变数，源代码如下所示：很显著，这儿的SQL快速查询便是漏洞开启实地了，咱们跟进DB_query这一变数，源代码如下所示：我们知道，要是在tp框架联接MySQL数据库中，如果我们应用PDO开展预编译的情况下，咱们的语句是难以更改原来的快速查询查看的，换句话说，注入的语句，难以开展快速查询，只有是作为字符串数组。拼凑从数据库层对注入进行了完全防护。那样这儿是怎么形成问题的呢？

0x01错误的处理造成的安全隐患

可是这儿有一个问题，便是当基本参数是二维数组的那时候，便会采用expandArguments这一形式，随后这一形式因为使用不当会造成安全隐患。咱们再总结一下下以前的快速查询语句，

这一二维数组我们都是可以控制的，最先在array_filter之后，应用foreach开展解析xml，随后两轮解析xml中两轮了1个新的二维数组。然后把$query变数中的键，开展了更换，更换掉之后的内容是以前新二维数组键用','开展那样成的1个新的字符串数组。那样咱们利用键来开展SQL注入就行的通了。注入语句可能利用拼凑进入。