为啥预编译SQL能够防止SQL注入

news/2024/10/31 5:27:36/

前言

之前我一个搞网络安全的朋友问了我一个的问题,为啥用 PreparedStatement 预编译的 SQL 就不会有被 SQL 注入的风险?

第一时间我联想到的是八股文中关于 Mybatis 的脚本 ${}#{} 的问题,不过再想想,为啥 ${} 会有 SQL 注入的风险,而 #{} 就没有?是因为到 PreparedStatement 做了什么处理吗?不知道。

然后我又想了想,预编译到底是个什么概念?预编译或者不预编译的 SQL 对数据库来说有什么区别吗?PreparedStatement 又在这个过程中扮演了怎样的角色?不知道。

好吧,我发现我确实对这个问题一无所知,看来需要亲自研究一下了。

一、数据库预编译

当我们说到关于持久层框架的功能,必然需要先想想这个功能的源头到底是不是直接通过数据库提供的。实际上和事务一样,SQL 预编译的功能也是需要数据库提供底层支持的。

1、预编译SQL的用法

以 MySQL 为例,在 MySQL 中,所谓预编译其实是指先提交带占位符的 SQL 模板,然后为其指定一个 key,MySQL 先将其编译好,然后用户再拿着 key 和占位符对应的参数让 MySQL 去执行,用法有点像 python 中的 format 函数。

一个标准的预编译 SQL 的用法如下:

prepare prepare_query from'select * from s_user where username = ?' # 提交带有占位符的参数化 SQL,也可以理解为 SQL 模板
set@name='%王五'; # 指定一个参数
execute prepare_query using@name; # 指定参数化 SQL 的 key 和参数,让 MySQL 自己去拼接执行

先通过 prepare 设置一个 SQL 模板,然后通过 execute 提交参数,MySQL 会自行根据参数替换占位符,到最后执行的 SQL 就是:

select*from s_user where username ='%王五'

2、预编译的原理

这里有个有意思问题,按网上的说法,prepare 执行的时候实际上 SQL 已经编译完了,所以可以防止注入,因为后续不管塞什么参数都不可能在调整语法树了,换个角度想,这是不是说明,如果我们一开始就让 prepare 执行的 SQL 模板的关键字变成占位符,是不是应该在这个时候就编译不通过?

比如,可以把查询的表名改成占位符:

prepare prepare_query from'select * from ? where username = ?'# >1064- You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to 
# use near '? where username = ?'at line 1

实际上也确实不行,因为编译时必须确定主表,因此在 from 后面加占位符会导致预编译不通过。

那么只在查询字段里面套一个嵌套查询呢?

prepare prepare_query from'select ? from s_user';
SET@c='(select * from s_user) as q';
EXECUTE prepare_query using@c;# 查询结果
# (select*from s_user) as q
# (select*from s_user) as q
# (select*from s_user) as q
# ......

查询成功了,不过得到的结果的固定的 (select * from s_user) 这个字符串,我们检查一下 MySQL 的执行日志,看看最终执行的 SQL 变成什么样了:

Prepare	select ? from s_user
Query	SET@c='(select * from s_user) as q'
Query	EXECUTE prepare_query using@cExecute	select'(select * from s_user) as q'from s_user # 最终执行的SQL

显然,(select * from s_user) 参数本身被直接转义为了一串普通的字符串,我们试图“注入”的 SQL 片段完全不会生效

换而言之,对于预编译 SQL 来说,我们作为模板的参数化 SQL 已经完成的编译过程,这段 SQL 包含几条有效语句?查哪张表?查哪些字段?作为条件的字段有哪些?......这些在 prepare 语句执行完后都是固定的,此后我们再通过 execute 语句塞进去的任何参数,都会进行转义,不会再作为 SQL 的一部分。这就是为什么说预编译 SQL 可以防止注入的原因。

二、JDBC的预编译

现在我们知道了预编译在数据库中是个怎样的功能,那么 JDBC 又是如何把这个功能提供给开发者使用的呢?

1、PreparedStatement

从最开始学 JDBC 时,我们就知道通过 JDBC 连接数据库一般是这样写的:

Class.forName(JDBC_DRIVER); // 加载驱动Connectionconnection= DriverManager.getConnection(URL, USERNAME, PASSWORD); // 获取连接PreparedStatementpreparedStatement= connection.prepareStatement(sql); // 获取sqlStatement
preparedStatement.setString(1, foo); // 设置参数ResultSetresultSet= preparedStatement.executeQuery(); // 执行SQL

这里有一个关键角色 PreparedStatement,相比起它的父接口 Statement,它最大的变化是多了各种格式为 setXXX 的、用于设置与占位符对应的参数的方法,显然它正对应着上文我们提到的预编译 SQL。

2、虚假的“预编译”

不过事情显然没有这么简单,我们依然以 MySQL 为例,默认情况下 MySQL 驱动包提供的 PreparedStatement 实现类 ClientPreparedStatement 也能起到防止 SQL 注入的功能,但是方式跟我们想的不太一样。

假设现有如下代码,我们尝试模拟进行一次 SQL 注入:

Stringsql="select * from s_user where username = ?";
PreparedStatementpreparedStatement= connection.prepareStatement(sql);
preparedStatement.setString(1, "王五' union select * from s_user");
ResultSetresultSet= preparedStatement.executeQuery();

运行上述代码并正常的请求数据库,然后我们去数据库执行日志中查看对应的执行的 SQL 如下,会发现只有这么一行:

Query select*from s_user where username ='王五'' union select * from s_user'

显然跟我们上文说到的先 prepareexecute 流程不同,带有占位符的原始 SQL 模板并没有在日志中出现,但是代码中的 王五' 确实也被转义为了 '王五''

数据库到底收到了哪些数据?

那么数据库到底拿到的就是这条 SQL,还是原始的 SQL 模板 + 参数呢?

为了了解这一点,我们打断点跟踪 ClientPreparedStatement.executeQuery 方法,一路找到它组装请求数据库的参数的那一行代码:

MessagesendPacket= ((PreparedQuery<?>) this.query).fillSendPacket();

最后我们会进入 AbstractPreparedQuery.fillSendPacket 这个方法,这里主要干的事是把我们带占位符的原始 SQL 模板和参数合并为最终要执行的 SQL ,并封装到 NativePacketPayload 对象,用于在后续发起 TCP 请求时把 SQL 参数转为二进制数据包。

为了验证这一点,我们先拿到 sendPacket 对象,再获取里面的字节数组,最后转为字符串:

可以看到内容就是已经格式化完的 SQL:

select*from s_user where username ='王五'' union select * from s_user'

现在答案就很明显了,转义在 preparedStatement.setString 方法调用的时候完成,而 PreparedStatement发起请求前就把转义后的参数和 SQL 模板进行了格式化,最后发送到 MySQL 的时候就是一条普通的 SQL

鉴于此,我们可以说 MySQL 提供的 PreparedStatement 在默认情况下是假的“预编译”,它只不过在设置参数的时候帮我们对参数做了一下转义,但是最后发送到数据库的依然是普通的 SQL,而不是按预编译 SQL 的方式去执行。

3、真正的预编译

好吧,那既然 MySQL 提供了这个预编译的功能,那通过 JDBC 肯定也还是有办法用上真正的预编译功能的,实际上要做到这点也很简单,就是直接在驱动的 url 上配上 useServerPrepStmts=true ,这样就会真正的启用 MySQL 的预编译功能。

依然以上文的代码为例:

Stringsql="select * from s_user where username = ?";
PreparedStatementpreparedStatement= connection.prepareStatement(sql);
preparedStatement.setString(1, "王五' union select * from s_user");
ResultSetresultSet= preparedStatement.executeQuery();

设置了 useServerPrepStmts=true 后再执行代码,去数据库查看执行日志有:

Executeselect*from s_user where username ='王五\'unionselect*from s_user'
Prepare select * from s_user where username = ?

此时 MySQL 的预编译功能就真正的生效了。

我们回到 ClientPreparedStatement.executeQuery 创建 sendPacket 地方看,此时通过 ((PreparedQuery<?>) this.query).fillSendPacket(); 拿到的 Message 对象是 null,然后进一步追踪到最后向 MySQL 发送请求的地方 NativeSession.execSQL

public <T extendsResultset> T execSQL(Query callingQuery, String query, int maxRows, NativePacketPayload packet, boolean streamResults,ProtocolEntityFactory<T, NativePacketPayload> resultSetFactory, ColumnDefinition cachedMetadata, boolean isBatch) {// ... ...try {// 如果 sendPacket 为 null,则调用 sendQueryString 方法,把原始 sql 和参数序列化为二进制数据包returnpacket== null? ((NativeProtocol) this.protocol).sendQueryString(callingQuery, query, this.characterEncoding.getValue(), maxRows, streamResults, cachedMetadata, resultSetFactory)// 否则调用 sendQueryPacket 方法,直接发送数据包: ((NativeProtocol) this.protocol).sendQueryPacket(callingQuery, packet, maxRows, streamResults, cachedMetadata, resultSetFactory);}// ... ...}

更具体的实现就不看了,基本都是关于序列化请求参数的逻辑。

三、Myabtis占位符与预编译

至此问题真相大白了,不过还是顺带扯一下八股文常提到的 Mybatis 占位符 #{}${} 是如何影响 SQL 注入问题的。

当然,看完上面的内容其实就已经很好猜到原因了:

  • #{} 对应的内容会作为 SQL 参数的一部分通过 PreparedStatement.setXXX 装入请求;

  • ${} 对应的内容会直接作为 SQL 模板的一部分,而不会视为独立的请求参数;

在 Mybatis 中,用于解析占位符的类为 GenericTokenParser ,根据它我们很容易在源码中找到占位符的处理方法,从而验证我们的猜想:

其中,#{} 占位符在 SqlSourceBuilder.ParameterMappingTokenHandler.handleToken 方法中处理:

public String handleToken(String content) {parameterMappings.add(buildParameterMapping(content));return"?";
}

可见 #{} 占位符会被解析为 ? 占位符,而对于的数据会被添加到 parameterMappings 用于后续塞到 PreparedStatement

${} 占位符在 PropertyParser.VariableTokenHandler.handleToken 方法中被处理:

public String handleToken(String content) {if (variables != null) {Stringkey= content;if (enableDefaultValue) {finalintseparatorIndex= content.indexOf(defaultValueSeparator);StringdefaultValue=null;if (separatorIndex >= 0) {key = content.substring(0, separatorIndex);defaultValue = content.substring(separatorIndex + defaultValueSeparator.length());}if (defaultValue != null) {return variables.getProperty(key, defaultValue);}}if (variables.containsKey(key)) {return variables.getProperty(key);}}return"${" + content + "}";
}

若占位符符合规范,则占会根据占位符中的内容去用户给定的参数中取值,并且让值直接替换掉原本 SQL 脚本中的 ${} 占位符。

这就是“ Mybatis#{} 而不是 ${} 可以防止 SQL 注入的真相

总结

回顾一下全文,当我们说“预编译”的时候,其实这个功能来自于数据库的支持,它的原理是先编译带有占位符的 SQL 模板,然后在传入参数让数据库自动替换 SQL 中占位符并执行,在这个过程中,由于预编译好的 SQL 模板本身语法已经定死,因此后续所有参数都会被视为不可执行的非 SQL 片段被转义,因此能够防止 SQL 注入。

当我们通过 JDBC 使用 PreparedStatement 执行预编译 SQL 的时候,此处的预编译实际上是假的预编译(至少 MySQL 是如此,不过其他数据库仍待确认),PreparedStatement 只是在设置参数的时候自动做了一层转义,最终提交给数据库执行的 SQL 仍然是单条的非预编译 SQL。

而当我们通过在驱动 url 上开启 useServerPrepStmts 配置后,预编译就会真正的生效,驱动包发往数据库的请求就会分成带占位符的 SQL 模板和参数,到了数据库再由数据库完成格式化并执行。

此外,八股文常提到的“Mybatis#{} 相比 ${} 可以防止 SQL 注入”这一点,本质上是因为 #{} 占位符会被解析为 SQL 模板中的 ? 占位符,而 ${} 占位符会被直接解析为 SQL 模板的一部分导致的。

最后脑补一下,由于 useServerPrepStmts 不开启时 PreparedStatement 的预编译实际上是假的预编译,所以理论上使用 #{} 也并非绝对安全,如果有办法绕过 PreparedStatement 的检查,那么数据库拿到被注入过的 SQL 直接执行,依然有暴毙的风险。


http://www.ppmy.cn/news/29820.html

相关文章

如何使用Spring Cloud搭建高可用的Elasticsearch集群?详解Elasticsearch的安装与配置及Spring Boot集成的实现

Spring Cloud 是一个基于 Spring Boot 的微服务框架&#xff0c;它提供了一系列组件和工具&#xff0c;方便开发人员快速搭建和管理分布式系统。Elasticsearch 是一个开源的全文搜索引擎&#xff0c;也是一个分布式、高可用的 NoSQL 数据库。本篇博客将详细讲解如何使用 Spring…

I.MX6ULL_Linux_系统篇(21) kernel启动流程

链接脚本 vmlinux.lds 要分析 Linux 启动流程&#xff0c;同样需要先编译一下 Linux 源码&#xff0c;因为有很多文件是需要编译才会生成的。首先分析 Linux 内核的连接脚本文件 arch/arm/kernel/vmlinux.lds&#xff0c;通过链接脚本可以 找到 Linux 内核的第一行程序是从哪里…

HTML、CSS学习笔记5(移动端基础知识、Flex布局)

一、移动端基础知识 1.PC端和移动端区别 移动端&#xff1a;手机版网页&#xff0c;手机屏幕小&#xff0c;网页宽度多数为100%&#xff0c;没有版心 PC端&#xff1a;电脑版网页&#xff0c;屏幕大&#xff0c;网页固定版心 PC端和移动端不是同一个网页 2.如何在电脑里面…

Python写一个自动发送直播弹幕的工具,非常简单

哈喽大家好&#xff0c;今天给大家用Python整一个可以在直播间自动发弹幕的工具&#xff0c;来为喜欢的主播疯狂扣6 &#xff01; 事情原由昨晚回家&#xff0c;表弟在看LOL直播&#xff0c;看得我气不打一处来&#xff0c;差点就想锤他。 身为程序员的表弟&#xff0c;看直…

自学大数据第三天~终于轮到hadoop了

前面那几天是在找大数据的门,其实也是在搞一些linux的基本命令,现在终于轮到hadoop了 Hadoop hadoop的安装方式 单机模式: 就如字面意思,在一台机器上运行,存储是采用本地文件系统,没有采用分布式文件系统~就如我们一开始入门的时候都是从本地开始的; 伪分布式模式 存储采用…

『Javascript基础重点』1.提前声明问题,你苦恼写了js函数代码但是不会生效的问题吗?

目录1. var与声明提前不可不说的故事2. 变量的声明提前例程2.1 对于函数内外值的改变&#xff08;关键区别&#xff0c;第二点和第三点目前没有遇到&#xff09;2.2 delete删除2.3 提升变量声明3. 函数的声明提前例程总结欢迎关注 『Javascript基础重点』 专栏&#xff0c;持续…

linux离线状态下将视频mp4格式转换m3u8

因为业务需求&#xff0c;python文件生成的视频为MP4格式&#xff0c;无法在前端浏览器正常播放&#xff0c;需切换m3u8格式&#xff0c;但因为服务器是没有网络的&#xff0c;因袭需要在离线状态下进行完成。 1.离线安装ffmpeg 看网上许多教程&#xff0c;ffmpeg可完成视频格…

员工入职流程自动化的原因

人和人之间的第一印象非常重要&#xff0c;一段缘分能不能开始&#xff0c;就看第一印象够不够给力了。其实&#xff0c;公司和新员工之间也存在着这样的关系&#xff0c;但也有些许差别。公司对新员工的第一印象&#xff0c;更多是从第一次见面的时候就产生了&#xff0c;而新…