昆明网站SQL注入竟然把我们的系统搞挂了，如何防止sql注入？

最近我在整理安全缝隙相关问题，预备在公司做一次分享。恰好，这段时刻团队发现了一个 sql 注入缝隙：在一个公共的分页功用中，排序字段作为入参，前端页面能够自界说。在分页 sql 的 mybatis mapper.xml 中，order by 字段后边运用 $ 符号动态接纳核算后的排序参数，这样能够完成动态排序的功用。

可是，假如入参传入：

id; select  1  --

终究履行的 sql 会变成：

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

--会把后边的 limit 句子注释掉，导致分页条件失效，回来了一切数据。进犯者能够经过这个缝隙一次性获取一切数据。

动态排序这个功用原本的想法是好的，可是却有 sql 注入的风险。值得庆幸的是，这次咱们及时发现了问题，并且及时处理了，没有造成什么丢失。

可是，几年前在老东家的时分，就没那么走运了。

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

一、还原事故现场

有一天运营小姐姐跑过来跟我说，有许多用户付出不了。这个付出服务是一个老体系，易手了 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 预编译机制后问题得以终究处理。

二、为什么会导致数据库衔接过多？

我信任许多同学看到这儿，都会有一个疑问：sql 注入为何会导致数据库衔接过多？

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

• 进犯者 sql 注入了相似这样的参数：-1;锁表句子--。

• 其间，前面的查询句子先履行了。

• 由于--后边的句子会被注释，接下来只会履行锁表句子，把表锁住。

• 正常事务恳求从数据库衔接池成功获取衔接后，需求操作表的时分，尝试获取表锁，但一向获取不到，直到超时。注意，这儿或许会累计很多的数据库衔接被占用，没有及时偿还。

• 数据库衔接池不够用，没有闲暇衔接。

• 新的事务恳求从数据库衔接池获取不到衔接，报数据库衔接过多反常。

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

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

preparestatement 预编译机制会在 sql 句子履行前，对其进行语法分析、编译和优化，其间参数方位运用占位符？替代了。

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

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

id; select  1  --

终究履行的 sql 会变成：

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

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

四、预编译就必定安全？

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

只会回来包含%的用户。

五、有些特别的场景怎么办？

在 java 中假如运用 mybatis 作为持久化结构，在 mapper.xml 文件中，假如入参运用 # 传值，会运用预编译机制。

一般咱们是这样用的：

   select * from user         name = #{name}

绝大多数状况下，鼓舞大家运用#这种办法传参，更安全，效率更高。

可是有时有些特别状况，比方：

   order by ${sortString}

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

运用 $ 的状况就有 sql 注入的风险。

那么这种状况该怎办呢？

• 自己写个 util 东西过滤掉一切的注入关键字，动态核算时调用该东西。

• 假如数据源用的阿里的 druid 的话，能够敞开 filter 中的 wall（防火墙），它包含了防止 sql 注入的功用。可是有个问题，便是它默许不允许多句子同时操作，对批量更新操作也会拦截，这就需求咱们自界说 filter 了。

六、表信息是怎么走漏的？

有些细心的同学，或许会提出一个问题：在上面锁表的比方中，进犯者是怎么拿到表信息的？

办法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 下面一切表名。

主张在生成环境程序拜访的数据库账号，要跟管理员账号分隔，必定要操控权限，不能拜访体系表。

七、sql注入到底有哪些危害？

7.1 核心数据走漏

大部分进犯者的目的是为了挣钱，说白了便是获取到有价值的信息拿出去卖钱，比方：用户账号、暗码、手机号、身份证信息、银行卡号、地址等灵敏信息。

他们能够注入相似这样的句子：

-1; select * from  user; --

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

所以，主张大家对这些灵敏信息加密存储，能够运用 AES 对称加密。

7.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 的管理员账号才干操作。

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

7.3 把体系搞挂

有些进犯者乃至能够直接把咱们的服务搞挂了，在老东家的时分便是这种状况。

他们能够注入相似这样的句子：

-1;锁表句子;--

把表长时刻锁住后，或许会导致数据库衔接耗尽。

这时，咱们需求对数据库线程做监控，假如某条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 防火墙，要么自己写代码逻辑过滤掉一切或许的注入关键字。