卧槽，SQL注入竟然把我们的系统搞挂了!

ゞ浴缸里的玫瑰 2022-10-31 10:49 252阅读 0赞

#  #

# 前言 #

先来给大家看个漫画，原创是xkcd，我把它翻译成了中文。

![format_png][]

如果你能在看漫画的时候能会心一笑，基本上就理解什么是SQL注入了，这里再啰嗦两句， 来个更简单的例子， 例如这个SQL做了字符串拼接：

"select * from user where id= " + userID

正常情况下没有问题， 但是，如果userID入参传入：

1 or 1=1

最终执行的SQL会变成：

select * from  user  where id=1 or 1=1

其中的`or 1=1`让前面的 id=1失去了作用，一下子把所有的用户都选出来了！

这是非常简单的案例，实际上我在老东家公司的时候，**一次SQL注入直接把我们支付服务搞挂了。**

# 1. 还原事故现场 #

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

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

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

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

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

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

使用命令：

set GLOBAL max_connections=500;

能及时生效，不需要重启mysql服务。

这次给我争取了更多的时间，找dba帮忙一起排查原因。

使用`show processlist;`命令查看当前线程执行情况：

![format_png 1][]还可以查看当前的连接状态帮助识别出有问题的查询语句。（需要特别说明的是上图只是我给的一个例子，线上真实的结果不是这样的）

*  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注入为何会导致数据库连接过多？

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

![format_png 2][]

1.  攻击者sql注入了类似这样的参数：`-1;锁表语句--`。
2.  其中`;`前面的查询语句先执行了。
3.  由于`--`后面的语句会被注释，接下来只会执行锁表语句，把表锁住。
4.  正常业务请求从数据库连接池成功获取连接后，需要操作表的时候，尝试获取表锁，但一直获取不到，直到超时。注意，这里可能会累计大量的数据库连接被占用，没有及时归还。
5.  数据库连接池不够用，没有空闲连接。
6.  新的业务请求从数据库连接池获取不到连接，报数据库连接过多异常。

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

# 3.表信息是如何泄露的？    #

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

### 方法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`。![format_png 3][]

第二步，获取表名。

传参改成：`-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`下面所有表名。

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

# 4.sql注入到底有哪些危害？ #

#### 1. 核心数据泄露 ####

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

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

-1; select * from  user; --

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

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

#### 2. 删库跑路 ####

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

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

-1; delete  from  user; --

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

-1; drop  database  test; --

以上语句会把整个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的管理员账号才能操作。

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

#### 3. 把系统搞挂 ####

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

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

-1;锁表语句;--

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

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

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

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

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

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

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

id; select 1 --

最终执行的sql会变成：

select * from user order by 'id; select 1 --' limit 1,20

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

# 6.预编译就一定安全？ #

不知道你在查询数据时有没有用过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 '%/%%';

只会返回包含`%`的用户。

# 7.有些特殊的场景怎么办？ #

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

一般我们是这样用的：

<sql id="query">
       select * fromuser
       <where>
         name = #{name}
       </where>
    </sql>

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

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

<sql id="orderBy">
       order by ${sortString}
    </sql>

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

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

那么这种情况该怎办呢？

1.  自己写个util工具过滤掉所有的注入关键字，动态计算时调用该工具。
2.  如果数据源用的阿里的druid的话，可以开启filter中的wall（防火墙），它包含了防止sql注入的功能。但是有个问题，就是它默认不允许多语句同时操作，对批量更新操作也会拦截，这就需要我们自定义filter了。

# 8. 防止sql注入的其他手段 #

#### 1. 要捕获异常    ####

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

#### 2. 使用代码检测工具 ####

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

#### 3. 要有监控 ####

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

#### 4. 数据库账号需控制权限 ####

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

#### 5. 代码review ####

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

#### 6. 使用其他手段处理 ####

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

![format_png 5][]

[码农翻身3年精华文章][3]

[漫画：康熙学不会二进制][Link 1]

[漫画：程序员必须要小心的七个潜规则][Link 2]

[漫画：兄弟，今晚又得熬个通宵了！][Link 3]

[架构师劝退指南][Link 4]

[程序员的宿命][Link 5]

[宇宙第一IDE到底是谁？][IDE]

[HTTP Server ：一个差生的逆袭][HTTP Server]

[如何降低程序员的工资？][Link 6]

[程序员，你得选准跑路的时间！][Link 7]

[Javascript: 一个屌丝的逆袭][Javascript_]

[我是一个线程][Link 8]

[TCP/IP之大明邮差][TCP_IP]

[一个故事讲完Https][Https]

[CPU 阿甘][CPU]

[format_png]: /images/20221024/30dc4b1c1e1141e6a6105653de50f436.png
[format_png 1]: /images/20221024/99e52478d6f24b7581f633ad3315a274.png
[format_png 2]: /images/20221024/83566e19077747028a7f50e531eaa7b3.png
[format_png 3]: /images/20221024/fc0eeddc784644f692210b2170760c8f.png
[format_png 4]: /images/20221024/a550fedf19844ef091aa5f2ef1958c93.png
[format_png 5]: /images/20221024/07efa3c8b52e40d78d5a02cf8b261d79.png
[3]: http://mp.weixin.qq.com/s?__biz=MzAxOTc0NzExNg%3D%3D&chksm=80d651cdb7a1d8db44237fec1fc2410da047ba639ba7e39edce3bbcdee28014718e6c6227b09&idx=1&mid=2665523598&scene=21&sn=ecb7512a1b1dbab5620d78c4963b5627#wechat_redirect
[Link 1]: http://mp.weixin.qq.com/s?__biz=MzAxOTc0NzExNg%3D%3D&chksm=80d650f9b7a1d9ef0e50493e8d6cf542bd117cbaca3a72776a5e60cf08ee63aa8144565ecbc0&idx=1&mid=2665523386&scene=21&sn=22aa6e097ed68baabfc7e29e1cdce73e#wechat_redirect
[Link 2]: http://mp.weixin.qq.com/s?__biz=MzAxOTc0NzExNg%3D%3D&chksm=80d65148b7a1d85e7f804de525b33c6297b113d1000df8d6fda2fcd0c05fc21a392ffb4cc740&idx=1&mid=2665523467&scene=21&sn=9ea85d80b1fc9a453c1ffb3f7f1049c7#wechat_redirect
[Link 3]: http://mp.weixin.qq.com/s?__biz=MzAxOTc0NzExNg%3D%3D&chksm=80d65927b7a1d031ec5e747627b86540056ed82006c300e2c8484b411447baf92d58ad8b6a82&idx=1&mid=2665521508&scene=21&sn=137269f8b286f3d9191be0ce9d6fdb1c#wechat_redirect
[Link 4]: http://mp.weixin.qq.com/s?__biz=MzAxOTc0NzExNg%3D%3D&chksm=80d667bbb7a1eeadb33b011a2fee71a4eb25635ebed0f4011f7c2b84b6103f18cd6633c299a8&idx=1&mid=2665521144&scene=21&sn=f7c7fd0ac7a26a22b64671a7f67faa8d#wechat_redirect
[Link 5]: http://mp.weixin.qq.com/s?__biz=MzAxOTc0NzExNg%3D%3D&chksm=80d66529b7a1ec3f9e266072ff2d4839df4082fa702d84be76e51d15326b34b7034278ce7ee4&idx=1&mid=2665520490&scene=21&sn=6dd71186fd2d648c29d69f541a8c7baf#wechat_redirect
[IDE]: http://mp.weixin.qq.com/s?__biz=MzAxOTc0NzExNg%3D%3D&chksm=80d661b1b7a1e8a70568d243a20c210eaf474650efc61e809dcf8e5d534be1d7f15ce1145295&idx=1&mid=2665519602&scene=21&sn=f85e22d32d4919116afbb2808f1a151a#wechat_redirect
[HTTP Server]: http://mp.weixin.qq.com/s?__biz=MzAxOTc0NzExNg%3D%3D&chksm=80d661efb7a1e8f9981903e2d7f0754449769973c80e5c7539930e89d7a3ffe0bdd74aabd8d5&idx=1&mid=2665519532&scene=21&sn=d17efeb01b6114fe20ea60d08c7836b2#wechat_redirect
[Link 6]: http://mp.weixin.qq.com/s?__biz=MzAxOTc0NzExNg%3D%3D&chksm=80d66df9b7a1e4ef28922b2241a998efd59cfc8d1693fe41b84d6ea31935d38feae2af68164a&idx=1&mid=2665518522&scene=21&sn=b1814b820074777a25281975df622e1c#wechat_redirect
[Link 7]: http://mp.weixin.qq.com/s?__biz=MzAxOTc0NzExNg%3D%3D&chksm=80d66eb1b7a1e7a72165940271001720e7853da6d324e6d9a0055b4a8c636d4bdbb7c1f1bfb9&idx=1&mid=2665518834&scene=21&sn=5dcedf3fc7e318f50cd32fffe38c429d#wechat_redirect
[Javascript_]: http://mp.weixin.qq.com/s?__biz=MzAxOTc0NzExNg%3D%3D&chksm=80d67820b7a1f136d73b874e5784f06ef34eb38d7750712a5b9c7532ad44f18a3d43d2edbfbd&idx=1&mid=2665513059&scene=21&sn=a2eaf97d9e3000d15a33681d1b720463#wechat_redirect
[Link 8]: http://mp.weixin.qq.com/s?__biz=MzAxOTc0NzExNg%3D%3D&chksm=06ef67ee3198eef85a668f7197709b54bcd9508087ace8f6eaa11d34eb4e5392c5190a77d530&idx=1&mid=416915373&scene=21&sn=f80a13b099237534a3ef777d511d831a#wechat_redirect
[TCP_IP]: http://mp.weixin.qq.com/s?__biz=MzAxOTc0NzExNg%3D%3D&chksm=80d678c5b7a1f1d3e122ae99f368671acb7f6baecebb6488c8ca63caa7f1ef28fea1a4dc1ef0&idx=1&mid=2665513094&scene=21&sn=a2accfc41107ac08d74ec3317995955e#wechat_redirect
[Https]: http://mp.weixin.qq.com/s?__biz=MzAxOTc0NzExNg%3D%3D&chksm=80d67b70b7a1f26697fa1626b3e9830dbdf4857d7a9528d22662f2e43af149265c4fd1b60024&idx=1&mid=2665513779&scene=21&sn=a1de58690ad4f95111e013254a026ca2#wechat_redirect
[CPU]: http://mp.weixin.qq.com/s?__biz=MzAxOTc0NzExNg%3D%3D&idx=1&mid=2665513017&scene=21&sn=5550ee714abd36d0b580713f673e670b#wechat_redirect