前言
最近我在整理安全漏洞相关问题，准备在公司做一次分享。恰好，这段时间团队发现了一个sql注入漏洞：在一个公共的分页功能中，排序字段作为入参，前端页面可以自定义。在分页sql的mybatismapper.xml中，order by字段后面使用$符号动态接收计算后的排序参数，这样可以实现动态排序的功能。
但是，如果入参传入：
id; select 1 --
最终执行的sql会变成：
select * from user order by id; select 1 -- limit 1,20
--会把后面的limit语句注释掉，导致分页条件失效，返回了所有数据。攻击者可以通过这个漏洞一次性获取所有数据。
动态排序这个功能原本的想法是好的，但是却有sql注入的风险。值得庆幸的是，这次我们及时发现了问题，并且及时解决了，没有造成什么损失。
但是，几年前在老东家的时候，就没那么幸运了。
一次sql注入直接把我们支付服务搞挂了。
正文
1. 还原事故现场
有一天运营小姐姐跑过来跟我说，有很多用户支付不了。这个支付服务是一个老系统，转手了3个人了，一直很稳定没有出过啥问题。
我二话不说开始定位问题了，先看服务器日志，发现了很多报数据库连接过多的异常。因为支付功能太重要了，当时为了保证支付功能快速恢复，先找运维把支付服务2个节点重启了。
5分钟后暂时恢复了正常。
我再继续定位原因，据我当时的经验判断一般出现数据库连接过多，可能是因为连接忘了关闭导致。但是仔细排查代码没有发现问题，我们当时用的数据库连接池，它会自动回收空闲连接的，排除了这种可能。
过了会儿，又有一个节点出现了数据库连接过多的问题。
但此时，还没查到原因，逼于无奈，只能让运维再重启服务，不过这次把数据库最大连接数调大了，默认是100，我们当时设置的500，后面调成了1000。（其实现在大部分公司会将这个参数设置成1000）
使用命令：
setGLOBAL max_connections=500;
能及时生效，不需要重启mysql服务。
这次给我争取了更多的时间，找dba帮忙一起排查原因。
使用show processlist;命令查看当前线程执行情况：
还可以查看当前的连接状态帮助识别出有问题的查询语句。（需要特别说明的是上图只是我给的一个例子，线上真实的结果不是这样的）
- id 线程id
- User 执行sql的账号
- Host 执行sql的数据库的ip和端号
- db 数据库名称
- Command 执行命令，包括：Daemon、Query、Sleep等。
- Time 执行sql所消耗的时间
- State 执行状态
- info 执行信息，里面可能包含sql信息。
果然，发现了一条不寻常的查询sql，执行了差不多1个小时还没有执行完。
dba把那条sql复制出来，发给我了。然后kill -9 杀掉了那条执行耗时非常长的sql线程。
后面，数据库连接过多的问题就没再出现了。
我拿到那条sql仔细分析了一下，发现一条订单查询语句被攻击者注入了很长的一段sql，肯定是高手写的，有些语法我都没见过。
但可以确认无误，被人sql注入了。
通过那条sql中的信息，我很快找到了相关代码，查询数据时入参竟然用的Statment，而非PrepareStatement预编译机制。
知道原因就好处理了，将查询数据的地方改成preparestatement预编译机制后问题得以最终解决。
2.为什么会导致数据库连接过多？
我相信很多同学看到这里，都会有一个疑问：sql注入为何会导致数据库连接过多？
我下面用一张图，给大家解释一下：
- 攻击者sql注入了类似这样的参数：
-1;锁表语句--。 - 其中
;前面的查询语句先执行了。 - 由于
--后面的语句会被注释，接下来只会执行锁表语句，把表锁住。 - 正常业务请求从数据库连接池成功获取连接后，需要操作表的时候，尝试获取表锁，但一直获取不到，直到超时。注意，这里可能会累计大量的数据库连接被占用，没有及时归还。
- 数据库连接池不够用，没有空闲连接。
- 新的业务请求从数据库连接池获取不到连接，报数据库连接过多异常。
sql注入导致数据库连接过多问题，最根本的原因是长时间锁表。
3.预编译为什么能防sql注入？
preparestatement预编译机制会在sql语句执行前，对其进行语法分析、编译和优化，其中参数位置使用占位符?代替了。
当真正运行时，传过来的参数会被看作是一个纯文本，不会重新编译，不会被当做sql指令。
这样，即使入参传入sql注入指令如：
id; select 1 --
最终执行的sql会变成：
select * from user order by 'id; select 1 --' limit 1,20
这样就不会出现sql注入问题了。
4.预编译就一定安全？
不知道你在查询数据时有没有用过like语句，比如：查询名字中带有“苏”字的用户，就可能会用类似这样的语句查询：
select * from user where name like '%苏%';
正常情况下是没有问题的。
但有些场景下要求传入的条件是必填的，比如：name是必填的，如果注入了：%，最后执行的sql会变成这样的：
select * from user where name like '%%%';
这种情况预编译机制是正常通过的，但sql的执行结果不会返回包含%的用户，而是返回了所有用户。
name字段必填变得没啥用了，攻击者同样可以获取用户表所有数据。
为什么会出现这个问题呢？
%在mysql中是关键字，如果使用like '%%%'，该like条件会失效。
如何解决呢？
需要对%进行转义：\%。
转义后的sql变成：
select * from user where name like '%\%%';
只会返回包含%的用户。
5.有些特殊的场景怎么办？
在java中如果使用mybatis作为持久化框架，在mapper.xml文件中，如果入参使用#传值，会使用预编译机制。
一般我们是这样用的：
<sql id="query"> select * fromuser <where> name = #{name} </where> </sql>
绝大多数情况下，鼓励大家使用#这种方式传参，更安全，效率更高。
但是有时有些特殊情况，比如：
<sql id="orderBy"> order by ${sortString} </sql>
sortString字段的内容是一个方法中动态计算出来的，这种情况是没法用#，代替$的，这样程序会报错。
使用$的情况就有sql注入的风险。
那么这种情况该怎办呢？
- 自己写个util工具过滤掉所有的注入关键字，动态计算时调用该工具。
- 如果数据源用的阿里的druid的话，可以开启filter中的wall（防火墙），它包含了防止sql注入的功能。但是有个问题，就是它默认不允许多语句同时操作，对批量更新操作也会拦截，这就需要我们自定义filter了。
6.表信息是如何泄露的？
有些细心的同学，可能会提出一个问题：在上面锁表的例子中，攻击者是如何拿到表信息的？
方法1：盲猜
就是攻击者根据常识猜测可能存在的表名称。
假设我们有这样的查询条件：
select * from t_order where id = ${id};
传入参数：-1;select * from user
最终执行sql变成：
select * from t_order where id = -1; select * from user;
如果该sql有数据返回，说明user表存在，被猜中了。
建议表名不要起得过于简单，可以带上适当的前缀，比如：t_user。这样可以增加盲猜的难度。
方法2：通过系统表
其实mysql有些系统表，可以查到我们自定义的数据库和表的信息。
假设我们还是以这条sql为例：
select code,name from t_order where id = ${id};
第一步，获取数据库和账号名。
传参为：-1 union select database(),user()#
最终执行sql变成：
select code,name from t_order where id = -1 union select database(),user()#
会返回当前 数据库名称：sue 和 账号名称：root@localhost。
第二步，获取表名。
传参改成：-1 union select table_name,table_schema from information_schema.tables where table_schema='sue'#最终执行sql变成：
select code,name from t_order where id = -1 union select table_name,table_schema from information_schema.tables where table_schema='sue'#
会返回数据库sue下面所有表名。
建议在生成环境程序访问的数据库账号，要跟管理员账号分开，一定要控制权限，不能访问系统表。
