SQL 注入竟然把我们的系统搞挂了

作者 | 苏三说技术责编 | 张文

来源 | 转载自 苏三说技术（ID： gh_9f551dfec941）

最近我在整理安全漏洞相关问题，准备在公司做一次分享。恰好，这段时间团队发现了一个 sql 注入漏洞：在一个公共的分页功能中，排序字段作为入参，前端页面可以自定义。在分页 sql 的 mybatis mapper.xml 中，order by 字段后面使用 $ 符号动态接收计算后的排序参数，这样可以实现动态排序的功能。

但是，如果入参传入：

最终执行的 sql 会变成：

--会把后面的 limit 语句注释掉，导致分页条件失效，返回了所有数据。攻击者可以通过这个漏洞一次性获取所有数据。

动态排序这个功能原本的想法是好的，但是却有 sql 注入的风险。值得庆幸的是，这次我们及时发现了问题，并且及时解决了，没有造成什么损失。

但是，几年前在老东家的时候，就没那么幸运了。

一次 sql 注入直接把我们支付服务搞挂了。

还原事故现场

有一天运营小姐姐跑过来跟我说，有很多用户支付不了。这个支付服务是一个老系统，转手了 3 个人了，一直很稳定没有出过啥问题。

我二话不说开始定位问题了，先看服务器日志，发现了很多报数据库连接过多的异常。因为支付功能太重要了，当时为了保证支付功能快速恢复，先找运维把支付服务 2 个节点重启了。

5 分钟后暂时恢复了正常。

我再继续定位原因，据我当时的经验判断一般出现数据库连接过多，可能是因为连接忘了关闭导致。但是仔细排查代码没有发现问题，我们当时用的数据库连接池，它会自动回收空闲连接的，排除了这种可能。

过了会儿，又有一个节点出现了数据库连接过多的问题。

但此时，还没查到原因，逼于无奈，只能让运维再重启服务，不过这次把数据库最大连接数调大了，默认是 100，我们当时设置的 500，后面调成了 1000。（其实现在大部分公司会将这个参数设置成 1000）

使用命令：

能及时生效，不需要重启 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 预编译机制后问题得以最终解决。

为什么会导致数据库连接过多？

我相信很多同学看到这里，都会有一个疑问：sql 注入为何会导致数据库连接过多？

我下面用一张图，给大家解释一下：

攻击者 sql 注入了类似这样的参数：-1;锁表语句--。

其中，前面的查询语句先执行了。

由于--后面的语句会被注释，接下来只会执行锁表语句，把表锁住。

正常业务请求从数据库连接池成功获取连接后，需要操作表的时候，尝试获取表锁，但一直获取不到，直到超时。注意，这里可能会累计大量的数据库连接被占用，没有及时归还。

数据库连接池不够用，没有空闲连接。

新的业务请求从数据库连接池获取不到连接，报数据库连接过多异常。

sql 注入导致数据库连接过多问题，最根本的原因是长时间锁表。

预编译为什么能防 sql 注入？

preparestatement 预编译机制会在 sql 语句执行前，对其进行语法分析、编译和优化，其中参数位置使用占位符？代替了。

当真正运行时，传过来的参数会被看作是一个纯文本，不会重新编译，不会被当做 sql 指令。

这样，即使入参传入 sql 注入指令如：

最终执行的 sql 会变成：

这样就不会出现 sql 注入问题了。

预编译就一定安全？

不知道你在查询数据时有没有用过 like 语句，比如：查询名字中带有“苏”字的用户，就可能会用类似这样的语句查询：

正常情况下是没有问题的。

但有些场景下要求传入的条件是必填的，比如：name 是必填的，如果注入了：%，最后执行的 sql 会变成这样的：

这种情况预编译机制是正常通过的，但 sql 的执行结果不会返回包含%的用户，而是返回了所有用户。

name 字段必填变得没啥用了，攻击者同样可以获取用户表所有数据。

为什么会出现这个问题呢？

% 在 mysql 中是关键字，如果使用 like '%%%'，该 like 条件会失效。

如何解决呢？

需要对 % 进行转义：/%。

转义后的 sql 变成：

只会返回包含%的用户。

有些特殊的场景怎么办？

在 java 中如果使用 mybatis 作为持久化框架，在 mapper.xml 文件中，如果入参使用 # 传值，会使用预编译机制。

一般我们是这样用的：

绝大多数情况下，鼓励大家使用#这种方式传参，更安全，效率更高。

但是有时有些特殊情况，比如：

sortString 字段的内容是一个方法中动态计算出来的，这种情况是没法用#，代替$的，这样程序会报错。

使用 $ 的情况就有 sql 注入的风险。

那么这种情况该怎办呢？

自己写个 util 工具过滤掉所有的注入关键字，动态计算时调用该工具。

如果数据源用的阿里的 druid 的话，可以开启 filter 中的 wall（防火墙），它包含了防止 sql 注入的功能。但是有个问题，就是它默认不允许多语句同时操作，对批量更新操作也会拦截，这就需要我们自定义 filter 了。

表信息是如何泄露的？

有些细心的同学，可能会提出一个问题：在上面锁表的例子中，攻击者是如何拿到表信息的？

方法1：盲猜

就是攻击者根据常识猜测可能存在的表名称。

假设我们有这样的查询条件：

传入参数：-1;select * from user

最终执行sql变成：

如果该sql有数据返回，说明user表存在，被猜中了。

建议表名不要起得过于简单，可以带上适当的前缀，比如：t_user。这样可以增加盲猜的难度。

方法2：通过系统表

其实 mysql 有些系统表，可以查到我们自定义的数据库和表的信息。

假设我们还是以这条 sql 为例：

第一步，获取数据库和账号名。

传参为：-1 union select database,user#

最终执行sql变成：

会返回当前 数据库名称：sue 和 账号名称：[email protected]。

第二步，获取表名。

传参改成：-1 union select table_name,table_schema from information_schema.tables where table_schema='sue'#最终执行sql变成：

会返回数据库 sue 下面所有表名。

建议在生成环境程序访问的数据库账号，要跟管理员账号分开，一定要控制权限，不能访问系统表。

sql注入到底有哪些危害？

7.1 核心数据泄露

大部分攻击者的目的是为了赚钱，说白了就是获取到有价值的信息拿出去卖钱，比如：用户账号、密码、手机号、身份证信息、银行卡号、地址等敏感信息。

他们可以注入类似这样的语句：

就能轻松把用户表中所有信息都获取到。

所以，建议大家对这些敏感信息加密存储，可以使用 AES 对称加密。

7.2 删库跑路

也不乏有些攻击者不按常理出牌，sql 注入后直接把系统的表或者数据库都删了。

他们可以注入类似这样的语句：

以上语句会删掉 user 表中所有数据。

以上语句会把整个 test 数据库所有内容都删掉。

正常情况下，我们需要控制线上账号的权限，只允许 DML（data manipulation language）数据操纵语言语句，包括：select、update、insert、delete 等。

不允许 DDL（data definition language）数据库定义语言语句，包含：create、alter、drop 等。

也不允许 DCL（Data Control Language）数据库控制语言语句，包含：grant,deny,revoke 等。

DDL 和 DCL 语句只有 dba 的管理员账号才能操作。

顺便提一句：如果被删表或删库了，其实还有补救措施，就是从备份文件中恢复，可能只会丢失少量实时的数据，所以一定有备份机制。

7.3 把系统搞挂

有些攻击者甚至可以直接把我们的服务搞挂了，在老东家的时候就是这种情况。

他们可以注入类似这样的语句：

把表长时间锁住后，可能会导致数据库连接耗尽。

这时，我们需要对数据库线程做监控，如果某条sql执行时间太长，要邮件预警。此外，合理设置数据库连接的超时时间，也能稍微缓解一下这类问题。

从上面三个方面，能看出sql注入问题的危害真的挺大的，我们一定要避免该类问题的发生，不要存着侥幸的心理。如果遇到一些不按常理出票的攻击者，一旦被攻击了，你可能会损失惨重。

如何防止 sql 注入？

8.1 使用预编译机制

尽量用预编译机制，少用字符串拼接的方式传参，它是sql注入问题的根源。

8.2 要对特殊字符转义

有些特殊字符，比如：%作为like语句中的参数时，要对其进行转义处理。

8.3 要捕获异常

需要对所有的异常情况进行捕获，切记接口直接返回异常信息，因为有些异常信息中包含了 sql 信息，包括：库名，表名，字段名等。攻击者拿着这些信息，就能通过 sql
注入随心所欲的攻击你的数据库了。目前比较主流的做法是，有个专门的网关服务，它统一暴露对外接口。用户请求接口时先经过它，再由它将请求转发给业务服务。这样做的好处是：能统一封装返回数据的返回体，并且如果出现异常，能返回统一的异常信息，隐藏敏感信息。此外还能做限流和权限控制。

8.4 使用代码检测工具

使用sqlMap等代码检测工具，它能检测sql注入漏洞。

8.5 要有监控

需要对数据库 sql 的执行情况进行监控，有异常情况，及时邮件或短信提醒。

8.6 数据库账号需控制权限

对生产环境的数据库建立单独的账号，只分配DML相关权限，且不能访问系统表。切勿在程序中直接使用管理员账号。

8.7 代码review

建立代码review机制，能找出部分隐藏的问题，提升代码质量。

8.8 使用其他手段处理

对于不能使用预编译传参时，要么开启 druid 的 filter 防火墙，要么自己写代码逻辑过滤掉所有可能的注入关键字。

☞破圈！不止于浏览器，WebAssembly 2020 大事记

☞X86 "将死"？RISC-V 正当立

☞C++落选，2021年最想学习的五大编程语言