正文

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. 使用其他手段处理

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