在owasp年度top 10安全问题中，注入高居榜首。SQL注入攻击指的是通过构建特殊的输入作为参数传入Web应用程序。而这些输入大都是SQL语法里的一些组合，通过执行SQL语句进而执行攻击者所要的操作，其主要原因是程序没有细致地过滤用户输入的数据，致使非法数据侵入系统。

• 2.通过SQL注入攻击，可以获取、修改、删除数据库信息，并且通过提权来控制Web服务器等其他操作;
• 3. SQL注入即攻击者通过构造特殊的SQL语句，入侵目标系统，致使后台数据库泄露数据的过程;
• 4.因为SQL注入漏洞造成的严重危害性，所以常年稳居0WASP TOP10的榜首!
  

1. 拖库导致用户数据泄漏;
2. 危害web等应用的安全;
3. 失去操作系统的控制权;
4. 危害企业及国家的安全!

现实生产环境中mysql用的居多。对mysql没有基础的童鞋可以参考我这篇文章，简单了解一下mysql（主要了解mysql一些查询语句）。

（1）联合查询常应用在SQL注入中，下面看一个例子，将下面的A和B这两个SQL语句联合，这样就可以执行查询到B里的内容。

（2）需要注意的是union查询前后字段数必须相同，不一致的话就会报错，e.g.:

（3）判断union前后字段是否一致，可以猜字段数：

猜到之后就可以利用union查询了，多余的字段不想查询可以用数字代替：

mysql中默认有information_schema数据库，这个类似于数据字典，存放数据库中所有的数据库和表及columns等。

这个数据库中我们主要先关注tables和columns这两张表。

（1）查询数据库库名、表名（tables），下面几句SQL语句执行下熟悉下：

（2）查询数据库名，表名和字段名 （columns）

1. 判断是否有SQL注入漏洞；
2. 判断操作系统、数据库和web应用的类型；
3. 获取数据库信息，包括管理员信息及拖库；

先查看后端代码：可以知道这边查询只有两个字段，然后输出三个字段信息。

5.1 基于错误的注入

错误注入的思路是通过构造特殊的sql语句，根据得到的错误信息，确认sql注入点;

通过数据库报错信息,也可以探测到数据库的类型和其他有用信息。

通过输入单引号,触发数据库异常，通过异常日志诊断数据库类型，例如这里是MySQL数据库。

5.2 基于时间的盲注

利用sleep()函数，检测SQL语句是否执行，如果在执行，说明是存在SQL注入点的。

5.3 基于布尔的注入

这样就获取了所有信息，说明一下：

• 第一个'用于闭合前面的条件
• -- 将注释后面的所有语句

union利用原始SQL语句进而查询自己想要的信息。一般通过错误和布尔注入点之后，就可以开始通过union语句来获取有效信息。

（1）下面我们应该猜测数据列数，从而才可以将union前后字段匹配（前面讲union说明了猜测的用法，可以回看哦）。

下面直接界面测试，一个一个尝试：

 知道出现以下情况，说明SQL语句中有两个字段：

（2）知道字段数后，就可以获取当前数据库及用户信息。

当前还以查看很多信息了，大可类比，自己动手操作下，好好想！比如：

SQL注入比较好用的工具,首推开源工具SQLmap。SQLmap是个国内外著名的安全稳定性测试工具,可以用来进行自动化检测，利用SQL注入漏洞，获取数据库服务器的权限。它具有功能强大的检测引擎，针对各种不同类型数据库的安全稳定性测试的功能选项，包括获取数据库中存储的数据，访问操作系统文件甚至可以通过外带数据连接的方式执行操作系统命令。

在本次实验我用的用的是kali自带的sqlmap工具：

（2）我们练习下，首先登录到user info界面。

（3）随便输入一个账号信息，错误的也行。然后复制出错的URL链接。

打开kali，下面看几个示例：

比如我知道了WordPress的账号和密码就可以登录上去查看啦：

（1）下面我们开始注入DVWA这个应用，由于进入DVWA需要账号密码，在加上cookie缓存，再进入DVWA下面其他应用就不需要密码。但是直接注入SQL injection是不可以的，需要加上cookie参数。

 可以尝试直接注入（下面提示你不可注入，你可以尝试风险级别）：

提高注入级别，依然没法注入：

（2）所以要利用cookie参数，我们先了解下客户机和服务器之间访问的原理，用户访问服务器，输入密码，这样在服务器端就产生session会话信息，保存session ID，对应的用户端产生cookie保存服务器的session。这样客户端在保持会话的时候就不用重复输入密码。可借鉴下图：

然后打开它，把cookie里的内容作为参数加入命令中：

（2）与操作系统交互（这个可能因为权限问题没办法登上去）

7 如何防御SQL注入

根据以上SQL注入的学习，我们应该知道SQL注入的攻击流程，所以我们应该相应的采取一系列措施。

1. 首先是mysql的安全机制，针对每个库对单独一个用户授权；
2. 对于单引号' 基于错误的注入，应该给予强制过滤；
3. 建议在web服务器前加一个WAF防火墙，对SQL注入进行拦截。

今日份打卡，over！

10. SQL是一种数据库结构化查询语言，SQL注入攻击的首要目标是()。

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

最终执行的sql会变成：

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

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

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

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

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

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

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

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

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

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

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

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

还可以查看当前的连接状态帮助识别出有问题的查询语句。

• info 执行信息，里面可能包含sql信息。

果然，发现了一条不寻常的查询sql，执行了差不多1个小时还没有执行完。

dba把那条sql复制出来，发给我了。然后kill -9 杀掉了那条执行耗时非常长的sql线程。

后面，数据库连接过多的问题就没再出现了。

我拿到那条sql仔细分析了一下，发现一条订单查询语句被攻击者注入了很长的一段sql，肯定是高手写的，有些语法我都没见过。

但可以确认无误，被人sql注入了。

通过那条sql中的信息，我很快找到了相关代码，查询数据时入参竟然用的Statment，而非PrepareStatement预编译机制。

知道原因就好处理了，将查询数据的地方改成preparestatement预编译机制后问题得以最终解决。

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

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

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

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

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

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

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

最终执行的sql会变成：

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

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

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

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

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

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

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

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

只会返回包含%的用户。

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

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

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

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

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

那么这种情况该怎办呢？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2. 要对特殊字符转义

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

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

4. 使用代码检测工具

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

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

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

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

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

8. 使用其他手段处理

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