mysql字符串拼接_重新学习MySQL数据库11：以Java的视角来聊聊SQL注入

本文转自互联网

本系列文章将整理到我在GitHub上的《Java面试指南》仓库&＃xff0c;更多精彩内容请到我的仓库里查看

https://github.com/h2pl/Java-Tutorial

喜欢的话麻烦点下Star哈

文章首发于我的个人博客&＃xff1a;

http://www.how2playlife.com

本文是微信公众号【Java技术江湖】的《重新学习MySQL数据库》其中一篇&＃xff0c;本文部分内容来源于网络&＃xff0c;为了把本文主题讲得清晰透彻&＃xff0c;也整合了很多我认为不错的技术博客内容&＃xff0c;引用其中了一些比较好的博客文章&＃xff0c;如有侵权&＃xff0c;请联系作者。

该系列博文会告诉你如何从入门到进阶&＃xff0c;从sql基本的使用方法&＃xff0c;从MySQL执行引擎再到索引、事务等知识&＃xff0c;一步步地学习MySQL相关技术的实现原理&＃xff0c;更好地了解如何基于这些知识来优化sql&＃xff0c;减少SQL执行时间&＃xff0c;通过执行计划对SQL性能进行分析&＃xff0c;再到MySQL的主从复制、主备部署等内容&＃xff0c;以便让你更完整地了解整个MySQL方面的技术体系&＃xff0c;形成自己的知识框架。

如果对本系列文章有什么建议&＃xff0c;或者是有什么疑问的话&＃xff0c;也可以关注公众号【Java技术江湖】联系作者&＃xff0c;欢迎你参与本系列博文的创作和修订。

本文转自互联网

本系列文章将整理到我在GitHub上的《Java面试指南》仓库&＃xff0c;更多精彩内容请到我的仓库里查看

https://github.com/h2pl/Java-Tutorial

喜欢的话麻烦点下Star哈

文章首发于我的个人博客&＃xff1a;

http://www.how2playlife.com

本文是微信公众号【Java技术江湖】的《重新学习MySQL数据库》其中一篇&＃xff0c;本文部分内容来源于网络&＃xff0c;为了把本文主题讲得清晰透彻&＃xff0c;也整合了很多我认为不错的技术博客内容&＃xff0c;引用其中了一些比较好的博客文章&＃xff0c;如有侵权&＃xff0c;请联系作者。

该系列博文会告诉你如何从入门到进阶&＃xff0c;从sql基本的使用方法&＃xff0c;从MySQL执行引擎再到索引、事务等知识&＃xff0c;一步步地学习MySQL相关技术的实现原理&＃xff0c;更好地了解如何基于这些知识来优化sql&＃xff0c;减少SQL执行时间&＃xff0c;通过执行计划对SQL性能进行分析&＃xff0c;再到MySQL的主从复制、主备部署等内容&＃xff0c;以便让你更完整地了解整个MySQL方面的技术体系&＃xff0c;形成自己的知识框架。

如果对本系列文章有什么建议&＃xff0c;或者是有什么疑问的话&＃xff0c;也可以关注公众号【Java技术江湖】联系作者&＃xff0c;欢迎你参与本系列博文的创作和修订。

前言

靶场准备

首先我们来准备一个web接口服务&＃xff0c;该服务可以提供管理员的信息查询&＃xff0c;这里我们采用springboot &＃43; jersey 来构建web服务框架&＃xff0c;数据库则采用最常用的mysql。下面&＃xff0c;我们来准备测试环境&＃xff0c;首先建立一张用户表jwtk_admin&＃xff0c;SQL如下&＃xff1a;

然后插入默认的管理员&＃xff1a;

这样我们就有了两位系统内置管理员了&＃xff0c;管理员密码采用MD5进行Hash&＃xff0c;当然这是一个很简单的为了作为研究靶场的表&＃xff0c;所以没有很全的字段。

接下来&＃xff0c;我们创建 spring boot &＃43; jersey 构建的RESTFul web服务&＃xff0c;这里我们提供了一个通过管理员用户名查询管理员具体信息的接口&＃xff0c;如下&＃xff1a;

SQL注入测试

首先我们以开发者正向思维向web服务发送管理员查询请求&＃xff0c;这里我们用PostMan工具发送一个GET请求

不出我们和开发者所料&＃xff0c;Web接口返回了我们想要的结果&＃xff0c;用户名为admin的管理员信息。OK&＃xff0c;现在开发任务完成&＃xff0c;Git Push&＃xff0c;Jira任务点为待测试&＃xff0c;那么这样的接口就真的没有问题了吗&＃xff1f;现在我们发送这样一条GET请求&＃xff1a;

发送该请求后&＃xff0c;我们发现PostMan没有接收到返回结果&＃xff0c;而Web服务后台却开始抛 MySQLSyntaxErrorException异常了&＃xff0c;错误如下&＃xff1a;

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 ‘‘xxxx’’’ at line 1

原因是在我们查询的 xxxx’ 处sql语句语法不正确导致。这里我们先不讨论SQL语法问题&＃xff0c;我们继续实验&＃xff0c;再次构造一条GET查询请求:

此时&＃xff0c;我们可以惊讶的发现&＃xff0c;查询接口非但没有报错&＃xff0c;反而将我们数据库jwti_admin表中的所有管理员信息都查询出来了&＃xff1a;

这是什么鬼&＃xff0c;难道管理员表中还有 name&＃61;xxxx’or’a’&＃61;&＃39;a 的用户&＃xff1f;这就是 SQL Injection。

注入原理分析

在接口中接受了一个String类型的name参数&＃xff0c;并且通过字符串拼接的方式构建了查询语句。在正常情况下&＃xff0c;用户会传入合法的name进行查询&＃xff0c;但是黑客却会传入精心构造的参数&＃xff0c;只要参数通过字符串拼接后依然是一句合法的SQL查询&＃xff0c;此时SQL注入就发生了。正如我们上文输入的name&＃61;xxxx’or’a’&＃61;&＃39;a与我们接口中的查询语句进行拼接后构成如下SQL语句&＃xff1a;

当接口执行此句SQL后&＃xff0c;系统后台也就相当于拱手送给黑客了&＃xff0c;黑客一看到管理员密码这个hash&＃xff0c;都不用去cmd5查了&＃xff0c;直接就用123456密码去登录你的后台系统了。Why&＃xff1f;因为123456的md5哈希太常见了&＃xff0c;别笑&＃xff0c;这就是很多中小网站的现实&＃xff0c;弱口令横行&＃xff0c;不见棺材不落泪&＃xff01;

好了&＃xff0c;现在我们应该明白了&＃xff0c;SQL Injection原因就是由于传入的参数与系统的SQL拼接成了合法的SQL而导致的&＃xff0c;而其本质还是将用户输入的数据当做了代码执行。在系统中只要有一个SQL注入点被黑客发现&＃xff0c;那么黑客基本上可以执行任意想执行的SQL语句了&＃xff0c;例如添加一个管理员&＃xff0c;查询所有表&＃xff0c;甚至“脱裤” 等等&＃xff0c;当然本文不是讲解SQL注入技巧的文章&＃xff0c;这里我们只探讨SQL注入发生的原因与防范方法。

JDBC的预处理

在上文的接口中&＃xff0c;DAO使用了比较基础的JDBC的方式进行数据库操作&＃xff0c;直接使JDBC构建DAO在比较老的系统中还是很常见的&＃xff0c;但这并不意味着使用JDBC就一定不安全&＃xff0c;如果我将传入的参数 xxxx’or’a’&＃61;&＃39;a 整体作为参数进行name查询&＃xff0c;那就不会产生SQL注入。在JDBC中&＃xff0c;提供了 PreparedStatement &＃xff08;预处理执行语句&＃xff09;的方式&＃xff0c;可以对SQL语句进行查询参数化&＃xff0c;使用预处理后的代码如下&＃xff1a;

同样&＃xff0c;我们使用上文的注入方式注入 &＃xff0c;此时我们发现&＃xff0c;SQL注入没能成功。现在&＃xff0c;我们来打印一下被被预处理后的SQL&＃xff0c;看看有什么变化&＃xff1a;

看到了吗?所有的 ’ 都被 ’ 转义掉了,从而可以确保SQL的查询参数就是参数&＃xff0c;不会被恶意执行&＃xff0c;从而防止了SQL注入。

Mybatis下注入防范

MyBatis 是支持定制化 SQL、存储过程以及高级映射的优秀的持久层框架&＃xff0c; 其几乎避免了所有的 JDBC 代码和手动设置参数以及获取结果集。同时&＃xff0c;MyBatis 可以对配置和原生Map使用简单的 XML 或注解&＃xff0c;将接口和 Java 的 POJOs(Plain Old Java Objects,普通的 Java对象)映射成数据库中的记录&＃xff0c;因此mybatis现在在市场中采用率也非常高。这里我们定义如下一个mapper&＃xff0c;来实现通过用户名查询管理员的接口&＃xff1a;

同样提供Web访问接口&＃xff1a;

接下来&＃xff0c;我们尝试SQL注入name字段&＃xff0c;可以发现注入并没有成功&＃xff0c;通过打印mybatis的Log可以看到mybatis框架对参数进行了预处理处理&＃xff0c;从而防止了注入&＃xff1a;

那是否只要使用了mybatis就一定可以避免SQL注入的危险&＃xff1f;我们把mapper做如下修改&＃xff0c;将参数#{name}修改为${name}&＃xff0c;并使用name&＃61;‘xxxx’ or ‘a’&＃61;‘a’ 作为GET请求的参数&＃xff0c;可以发现SQL注入还是发生了&＃xff1a;

那这是为什么&＃xff0c;mybatis ${}与#{}的差别在哪里&＃xff1f;

原来在mybatis中如果以形式声明为SQL传递参数&＃xff0c;mybatis将不会进行参数预处理&＃xff0c;会直接动态拼接SQL语句&＃xff0c;此时就会存在被注入的风险&＃xff0c;所以在使用mybatis作为持久框架时应尽量避免采用

形式声明为SQL传递参数&＃xff0c;mybatis将不会进行参数预处理&＃xff0c;会直接动态拼接SQL语句&＃xff0c;此时就会存在被注入的风险&＃xff0c;所以在使用mybatis作为持久框架时应尽量避免采用形式声明为SQL传递参数。

mybatis将不会进行参数预处理&＃xff0c;会直接动态拼接SQL语句&＃xff0c;此时就会存在被注入的风险&＃xff0c;所以在使用mybatis作为持久框架时应尽量避免采用{}的形式进行参数传递&＃xff0c;如果无法避免&＃xff08;有些SQL如like、in、order by等&＃xff0c;程序员可能依旧会选择${}的方式传参&＃xff09;&＃xff0c;那就需要对传入参数自行进行转义过滤。

JPA注入防范

JPA是Sun公司用来整合ORM技术&＃xff0c;实现天下归一的ORM标准而定义的Java Persistence API&＃xff08;java持久层API&＃xff09;&＃xff0c;JPA只是一套接口&＃xff0c;目前引入JPA的项目都会采用Hibernate作为其具体实现&＃xff0c;随着无配置Spring Boot框架的流行&＃xff0c;JPA越来越具有作为持久化首选的技术&＃xff0c;因为其能让程序员写更少的代码&＃xff0c;就能完成现有的功能。

例如强大的JpaRepository&＃xff0c;常规的SQL查询只需按照命名规则定义接口&＃xff0c;便可以不写SQL&＃xff08;JPQL/SQL&＃xff09;就可以实现数据的查询操作&＃xff0c;从SQL注入防范的角度来说&＃xff0c;这种将安全责任抛给框架远比依靠程序员自身控制来的保险。因此如果项目使用JPA作为数据访问层&＃xff0c;基本上可以很大程度的消除SQL注入的风险。

但是话不能说的太死&＃xff0c;在我见过的一个Spring Boot项目中&＃xff0c;虽然采用了JPA作为持久框架&＃xff0c;但是有一位老程序员不熟悉于使用JPQL来构建查询接口&＃xff0c;依旧使用字符串拼接的方式来实现业务&＃xff0c;而为项目安全埋下了隐患。

安全需要一丝不苟&＃xff0c;安全是100 - 1 &＃61; 0的业务&＃xff0c;即使你防御了99%的攻击&＃xff0c;那还不算胜利&＃xff0c;只要有一次被入侵了&＃xff0c;那就有可能给公司带来很严重的后果。

关于JPA的SQL注入&＃xff0c;我们就不详细讨论了&＃xff0c;因为框架下的注入漏洞属于框架漏洞范畴&＃xff08;如CVE-2016-6652&＃xff09;&＃xff0c;程序员只要遵循JPA的开发规范&＃xff0c;就无需担心注入问题&＃xff0c;框架都为你做好幕后工作了。

SQL注入的其他防范办法

很多公司都会存在老系统中有大量SQL注入风险代码的问题&＃xff0c;但是由于其已稳定支持公司业务很久&＃xff0c;不宜采用大面积代码更新的方式来消除注入隐患&＃xff0c;所以需要考虑其采用他方式来防范SQL注入。除了在在SQL执行方式上防范SQL注入&＃xff0c;很多时候还可以通过架构上&＃xff0c;或者通过其他过滤方式来达到防止SQL注入的效果。

一切输入都是不安全的&＃xff1a;对于接口的调用参数&＃xff0c;要进行格式匹配&＃xff0c;例如admin的通过name查询的接口&＃xff0c;与之匹配的Path应该使用正则匹配&＃xff08;因为用户名中不应该存在特殊字符&＃xff09;&＃xff0c;从而确保传入参数是程序控制范围之内的参数&＃xff0c;即只接受已知的良好输入值&＃xff0c;拒绝不良输入。注意&＃xff1a;验证参数应将它与输出编码技术结合使用。

利用分层设计来避免危险&＃xff1a;前端尽量静态化&＃xff0c;尽量少的暴露可以访问到DAO层的接口到公网环境中&＃xff0c;如果现有项目&＃xff0c;很难修改存在注入的代码&＃xff0c;可以考虑在web服务之前增加WAF进行流量过滤&＃xff0c;当然代码上就不给hacker留有攻击的漏洞才最好的方案。也可以在拥有nginx的架构下&＃xff0c;采用OpenRestry做流量过滤&＃xff0c;将一些特殊字符进行转义处理。

尽量使用预编译SQL语句&＃xff1a;由于动态SQL语句是引发SQL注入的根源。应使用预编译语句来组装SQL查询。

规范化&＃xff1a;将输入安装规定编码解码后再进行输入参数过滤和输出编码处理&＃xff1b;拒绝一切非规范格式的编码。

小结

其实随着ORM技术的发展&＃xff0c;Java web开发在大趋势上已经越来越远离SQL注入的问题了&＃xff0c;而有着Entity Framework框架支持的http://ASP.NET MVC从来都是高冷范。在现在互联网中&＃xff0c;使用PHP和Python构建的web应用是目前SQL注入的重灾区。本文虽然是从JAVA的角度来研究SQL注入的问题&＃xff0c;但原理上同样适用于其他开发语言&＃xff0c;希望读者可以通过此文&＃xff0c;触类旁通。

珍爱数据&＃xff0c;远离拼接&＃xff0c;有输入的地方就会有江湖…