写点什么

sql 注入竟然把我们的系统搞挂了,怎么办?

发布于: 2021 年 02 月 07 日

前言

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


但是,如果入参传入:

id; select 1 --
复制代码


最终执行的 sql 会变成:

select * from test1 order by id; select 1 -- limit 1,20
复制代码

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


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


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


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


1. 还原事故现场

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


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


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


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


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


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


使用命令:

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


我下面用一张图,给大家解释一下:



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

  2. 其中;前面的查询语句先执行了。

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

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

  5. 数据库连接池不够用,没有空闲连接。

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


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


3.预编译为什么能防 sql 注入?

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


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


这样,即使入参传入 sql 注入指令如:

id; select 1 --
复制代码

最终执行的 sql 会变成:

select * from test1 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 * from user    <where>     name = #{name}   </where></sql>
复制代码

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


但是有时有些特殊情况,比如:

<sql id="orderBy">   order by ${sortString}</sql>
复制代码

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


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


那么这种情况该怎办呢?


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

  2. 如果数据源用的阿里的 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下面所有表名。



7.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 注入问题的危害真的挺大的,我们一定要避免该类问题的发生,不要存着侥幸的心理。如果遇到一些不按常理出票的攻击者,一旦被攻击了,你可能会损失惨重。


8. 如何防止 sql 注入?

1. 使用预编译机制

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


2. 要对特殊字符转义

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


3. 要捕获异常

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


4. 使用代码检测工具

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


5. 要有监控

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


6. 数据库账号需控制权限

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


7. 代码 review

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


8. 使用其他手段处理

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

发布于: 2021 年 02 月 07 日阅读数: 15
用户头像

还未添加个人签名 2018.07.31 加入

「苏三说技术」 维护者目前就职于某知名互联网公司,从事开发、架构和部分管理工作。实战经验丰富,对jdk、spring、springboot、springcloud、mybatis等开源框架源码有一定研究,欢迎关注和交流。

评论

发布
暂无评论
sql注入竟然把我们的系统搞挂了,怎么办?