用实际案例告诉你SQL注入漏洞是怎么回事

我是风筝，一个兼具深度与广度的程序员鼓励师，一个本打算写诗却写起了代码的田园码农！
文章会收录在 [JavaNewBee]github.com/huzhicheng/JavaNewBee中，更有 Java 后端知识图谱，从小白到大牛要走的路都在里面。

标题有点臭不要脸，有标题党之嫌了，没有黑，只是网站安全性做的太差，我一个初学者随便就搞到了管理员权限。

事情是这样子的，在10年以前，某个月黑风高夜的夜里，虽然这么说有点暴露年龄了，但无所谓，毕竟我也才18而已。我打开电脑，在浏览器中输入我们高中学校的网址，页面很熟悉，很简陋，也没什么设计感，不过学校的网站从来都是这种风格，直到今天依然是这样。

这次访问与以往有些不同，因为我的目的很明确。作为学校的一员，理应为学校做些贡献的，为学校官网找些安全漏洞也算贡献的一种吧（强烈的求生欲）。

之所以选择学校的官网，一来是因为熟悉，先从熟悉的东西下手，一定错不了。二来是因为之前使用网站的时候碰过到一些异常的页面，直接就是异常堆栈直接抛出来。正好那段时间对网络安全比较有兴趣，在研究SQL 注入的时候正好想到在学校官网上碰到的问题好像就存在 SQL 注入的风险。于是，顺理成章，我的第一个目标就锁定了学校官网。

问题就出在一个大概这样的搜索页面，真正的网站已经改版过好多次了，以前的页面找不到了。

当时我在上面随便输入了一些内容，里面含有单引号，然后一点击搜索，页面就直接出现了异常提示，类似于下面这样子的。别惊讶，当时很多网站都是这样的，异常是直接抛出来的，别说以前了，现在也不少。

于是我用那时候刚学会的皮毛知识，加上两个好用的工具，轻松拿到了数据库的数据，其中就包括了管理员的账号、密码，密码还是明文的，你说气人不。
然后通过后台管理员登录页面进入了管理员后台，当然了，只是进去看了看，什么都没碰，而且后台也没什么重要数据，顶多就是一些通知、新闻等数据。

我是怎么做到的呢，不说具体细节了，也确实没什么技术含量，而且时间太长也记不清了，后面就说一下 SQL 注入的原理和具体操作。

什么是 SQL 注入

SQL注入，是发生于应用程序与数据库层的安全漏洞。简而言之，是在输入的字符串之中注入SQL指令，在设计不良的程序当中忽略了字符检查，那么这些注入进去的恶意指令就会被数据库服务器误认为是正常的SQL指令而运行，因此遭到破坏或是入侵。

SQL 注入一般发生在用户交互场景中，比如需要用户自已输入信息的输入框，或者下拉选择选项的这种，如果不做好输入内容的过滤，就很可能发生 SQL 注入。

就拿这个登录界面来说，用户名和密码都是你要输入的内容，点击登录按钮之后，会把你输入的值传递到服务端，服务端再到数据库进行查询。

假设后端的查询语句是这样的，不要在乎这是什么语法，只是举个例子。

String sql = "select * from `user` where  account={account} and password={password}";


正常的情况，比如 account 输入的是一个电话号码 13001980988，密码是 123456，那拼接出的 SQL 语句就是
String sql = "select * from `user` where  account='13001980988' and password='123456'";

然后，服务端通过数据库连接执行这条语句：
select * from `user` where  account='13001980988' and password='123456';

最后，数据库正常返回符合条件的记录，代码中再根据结果进行判断，执行后面的逻辑。
不正常的输入
SQL 注入就是通过不正常的输入来获取程序开发者意料之外的结果。
什么是不正常的输入呢？
比如我在用户名输入框中输入的内容是这样子的 :13001980988' or 1=1 --，密码输入框随便输入什么都无所谓，然后点击登录，传输给后端，后端拼接出来的结果就是这样的：
String sql = "select * from `user` where  account='13001980988' or 1=1 --'  and password='123456'";

然后，服务端通过数据库连接会执行下面这条语句：
select * from `user` where  account='13001980988' or 1=1 --'  and password='123456'

以 MySQL 为例， -- 是 MySQL 中的注释符号，上面的语句中 --后面的相当于是注释内容了，所以最后实际执行的 SQL 语句是这样的：
select * from `user` where  account='13001980988' or 1=1 

于是，SQL 注入就这么发生了，显然有了 or 1=1 这个条件，表中所有的记录都符合条件。如果在用户名输入框中输入的是 admin、administrator 等已知的后台管理员账号，那就可以用管理员账号直接登录系统了。
上面就是 SQL 注入的基本原理。
SQL 注入遍地都是的年代
在9、10年前，也就是在我小时候（对，这个词好，小时候）。那时候智能手机才刚刚出来，塞班系统还很贵，根本就买不起。用着功能机，30M的流量能用坚持一个月，聊天只靠 QQ 和 短信，微信才刚要问世，更别提什么 APP 了，根本就没有。那时候，PC Web 才是根正苗红的网络主宰，如果说要在网上干点儿什么的话，那必须要有一个配套的网站才可以。
互联网还没有发展的这么成熟，用的技术也比较原始，绝大多数的网站是用 PHP 写的，还有很多用 ASP 。可能有些同学都不知道 ASP 是什么，它虽然也是微软的，但是却不是 ASP.NET。数据库很多用的是 MySQL ，还有一部分用的是更原始的 Access，可能又触到某些同学的盲区了，这不怪你没见识，只怪你太年轻。
一些小公司啊、学校啊、政府部门网站啊、各种论坛啊等等，各种五花八门的网站。不像现在这样，无论你用 PHP、Java 还是 Python，都有很多成熟的开发框架供你选择，成熟的框架必然会减少漏洞和降低被攻击的风险。但那时候没有这么多框架供选择，就比如很多学校会选择用 ASP + Access 组合的架构来开发自己的学校官网、教务管理系统等，功能上比较简单，但是全靠手工去写，就说 SQL 查询吧，从建立数据库连接到拼接 SQL 语句，再到执行查询处理查询结果，全都要自己实现，并没有什么 ORM 框架、数据库连接池供选择，由此就带来了 SQL 注入的风险。
而且建网站，如果不想开发的话，有很多 CMS 框架，尤其 PHP 的很多，现在依旧使用广泛的有 WordPress，当时国内的有 Discuz、DEDECMS 等一批傻瓜建站的 CMS 系统，由于代码都是开源的，而且 WordPress 还支持插件，所以会有很多相关的漏洞爆出来，尤其在多年以前，有了漏洞，想拿下一个网站真是太容易了，即使漏洞已经公布并有了解决方案，但依然有好多网站不及时修补和升级。现在在 Google 中搜索相关的 SQL注入关键词，有很多相关介绍。

说了这么多，这不都是 PHP 的代码吗？嘘，只是碰巧而已，说明 PHP 市场大呀，毕竟PHP是最好的开发语言。那 Java 中就没有了吗，当然有啊。
MyBatis 中的 SQL注入风险
最近在看一些代码，Spring Boot + MyBatis 的，偶然发现一个模糊查询的方法的 SQL 语句中用到了 like '%${keyword}%'这样的查询条件，这一看就有 SQL 注入漏洞。

大家可能都了解，MyBatis 是可以解决 SQL 注入的问题的。一般我们在使用 MyBatis 的时候都会把 SQL 语句单独的放到 xml 文件中，在 SQL 语句中支持两种格式的参数占位符，一种是 #{parameter}，另一种是 ${parameter}，在这两种参数占位符中，#{parameter}是安全的，不存在SQL注入漏洞，而 ${parameter}是存在 SQL 注入漏洞的。
安全的占位符格式
#{parameter} 这种占位符会在 MySQL中进行预编译，所以你观察到 MyBatis 打印出来的日志是这样的：
select * from `user` where  account=? and password=?

其实在框架底层，是 JDBC 中的 PreparedStatement 类在起作用，PreparedStatement 是我们很熟悉的 Statement 的子类，它的对象包含了编译好的SQL语句。这种预编译的方式不仅能提高安全性，而且在多次执行同一个SQL时，能够提高效率。原因是SQL已编译好，再次执行时无需再编译。
不知道你有没有写过直接用 JDBC 操作数据库的代码，反正大学老师就告诉我们要用占位符去做数据库查询，而不是拼接 SQL 字符串，因为用占位符的方式安全。其实，MyBatis 的预编译模式的底层实现就可以理解为下面这样的。
Connection conn = getConn();//获得连接
String sql = "select * from `user` where  account=? and password=?"; //执行sql前会预编译号该条语句
PreparedStatement pstmt = conn.prepareStatement(sql); 
pstmt.setString(1, "13001980988");
pstmt.setString(2, "123456");
ResultSet rs=pstmt.executeUpdate(); 

不安全的占位符格式
${parameter} 这种格式是不进行预编译的，也就相当于字符串的拼接，存在 SQL注入的问题，如果非要用这种方式，那需要在程序中对参数进行安全性校验。强烈建议在使用 MyBatis 的过程中不要使用 ${parameter}这种格式的占位符，而要使用 #{parameter}这种格式。
来一波SQL注入
我模拟了一个 SQL 注入的场景，很简单，就是一个模糊查询的接口，根据用户输入的关键词查询。
数据库中有两张表，分别为用户表（user）和 新闻表（news）。
用户表：

新闻表：

NewsMapper 类：
public interface NewsMapper {
    List selectNewsLikeTitle(@Param("keyword") String keyword);
}

实际的 SQL 语句，注意，正是用到了 ${keyword}，才有了 SQL 注入的问题。