0x00 前言

之前在写安全测试报告时,对于SQL注入的修复建议或者防御措施无非是两条:一是白名单限制,二是参数化查询。对于参数化查询的原理,停留于MySQL能先将SQL语句进行词法和语法解析,再将参数绑定执行的阶段。而我们在代码中用Prepared Statement语句实现参数化查询时,很可能事实并不是如此。

0x01 问题

网上关于预编译语句的文章有很多,但是,大部分都是基于片面的实验得到以偏概全的结论。争论最多的问题是一般情况下MySQL是否开启了服务端的预编译。网上众说纷纭,经过实验,我得出来的结论是MySQL是否开启服务端的预编译是由客户端连接时的参数useServerPrepStmts决定的,而在MySQL提供的Connector/J版本5.0.5(release 2007-03-02)之后,默认情况下,useServerPrepStmts=false。即如果没有显式设置成true,默认情况下,MySQL不启用服务端预编译。

那么我们在代码中使用预编译函数,例如Java中的prepareStatement,是否存在SQL注入的风险呢?

0x02 实验

实验之前先打开MySQL服务器的日志,在my.ini中加一行:

1
log="D:/mysql.log"

为了方便查看与MySQL服务器的通信,实验中使用了wireshark,如果MySQL服务器在本地,wireshark可能抓不到包,可以用本地ip连接MySQL服务器,不使用127.0.0.1或者localhost。并以管理员身份运行cmd,运行以下命令添加路由

1
route add 本地ip mask 255.255.255.255 本地网关

MySQL官网在Connector/J 5.0.5的变更中有如下内容

Important change: Due to a number of issues with the use of server-side prepared statements, Connector/J 5.0.5 has disabled their use by default. The disabling of server-side prepared statements does not affect the operation of the connector in any way.

To enable server-side prepared statements, add the following configuration property to your connector string:

useServerPrepStmts=true

The default value of this property is false (that is, Connector/J does not use server-side prepared statements).

大致意思是Connector/J 5.05及以后的版本中,默认情况下useServerPrepStmts的值是false,不使用服务端预编译。这里,我用的Connector/J版本是5.1.46。

首先,我们看一下useServerPrepStmts=true情况下wireshark的抓包和MySQL的日志。代码如下:
201803211422.PNG

运行代码,抓包如下:
201803211425.png
上面这个包是发送给要求MySQL服务器Prepare语句”select * from user where id=?”
201803211426.png
接下来发送填充到占位符的字符串的值,我们看到,在这里字符串没有被转义。
201803211427.png
这是MySQL的日志,可以明显看到,MySQL prepare了语句select * from user WHERE id=?,接着执行了select * from user WHERE id=’1\‘ or \‘1\‘=\‘1’。

很明显,MySQL服务器对SQL语句做了预编译。

接着,去掉useServerPrepStmts=true,在普通情况下会发生什么呢?
代码如下:
201803211434.png
201803211435.png

抓包发现,java程序仅向MySQL服务器发送了一个Query请求,而且Query的SQL语句是select * from user WHERE id=’1\‘ or \‘1\‘=\‘1’。

201803211437.png
从MySQL日志中,我们发现也确实如此。这是为什么呢?

0x03 客户端预编译

我们跟一下PreparedStatement statement = connection.prepareStatement(sql)这一句,F7跟进,在com.mysql.jdbc.ConnectionImpl中存在以下逻辑:
2792行:
201803211502.png

判断了一下useServerPreparedStmts是否打开和canServerPrepare是否为true,均为true则走下面调用服务端预编译的逻辑。而默认情况下,useServerPreparedStmts=false,因此,代码到2837行:
201803211503.png
调用clientPrepareStatement来对SQL语句进行处理。这样的话,对单引号等关键字符的转义在哪里做的呢?

我们接着来跟一下statement.setString(1, "1' or '1'='1");这一句。在com.mysql.jdbc.PreparedStatement中,2238行开始
201803211520.png
省略部分代码
201803211529.png
从2282行开始,对填充的字符串做转义处理,并在转义之后的字符串前后填加单引号。这段代码的主要作用是转义字符串,防止SQL注入。

0x04 试着突破它

这里转义的字符比较少,有没有漏掉一些字符,能够逃逸出单引号呢?我对SQL注入并不精通,凭空想出一些payload比较难,这里有两种方法可以试一下,一是参看类似的实现,例如php中addslashes的源代码,二是fuzz。

PHP的addslashes的源代码在ext/standard/string.c中。遗憾的是,并没有发现其他字符。

接下来是fuzz,Java中,字符的编码是utf16,Unicode的编码空间从U+0000到U+10FFFF,共有1,112,064个码位。进过fuzz测试,也没有发现能逃逸单引号的字符。

0x05 其他语言的客户端prepare

MySQL官方提供了各种语言连接MySQL的Connectors,其他语言的connectors是不是也默认客户端prepare呢?我测试了Python的,结果也是同样。其余Connectors有兴趣的读者可以自行测试。