web渗透测试-防sql注入

今天线上竟然遭受了攻击。还好在防护上做了功课，如果被攻破，后果不堪设想。

早上刚到办公室，Y就急匆匆的跑来说。据后端监测，有不少exception。貌似我们我们线上不能登陆了。然后大家也不知道发生了什么事，都很紧张。

然后让前端T去调查。T推三阻四，说后端没有给任何信息过来，他无从下手，为此竟然争执起来。Y让我去调查，无非找个人来背锅。

还好，我检测，线上正常。后端D也到了办公室。说是有几个账号的密码里面有双引号。而前端，是做了转义，是过滤掉了的。他们调查结果是遭受了攻击。可能是哪个菜鸡，拿我们产品练手吧。虽然我们的APP免费，可是每个账号价值不菲（价值1到2万块)。

攻击一直在持续，产品验收测试是我做的，这块是专门测试过的，所以有底气。安全小组出动，定位，捉拿归案。(莫伸手，伸手必被捉)

现在来聊聊如何防sql注入攻击。一般常见的web漏洞有如下：

SQL注入

XSS(Cross Site Scripting)跨站脚本攻击

CSRF（Cross-site request forgery）跨站请求伪造

弱口令

非加密传输

文件上传漏洞

SQL注入攻击是黑客攻击网站最常用的手段。开源Web应用程序安全项目（OWASP）在最近发布的OWASP Top 10 - 2017中继续将注入攻击（包含SQL注入及其它注入方式）作为十大最严重的Web应用程序安全风险榜的榜首。

SQL注入攻击之所以成为最常见的攻击方式，通常是因为数据库中存储了应用程序所有重要的、有价值的数据，比如用户信息。在过去的几年里，有百分之九十的数据泄漏事件都与这种手段有关。

虽然SQL注入攻击如此常见，但要避免代码中出现SQL注入漏洞却是极其简单的。

SQL注入漏洞产生的原因是，程序员们在动态创建数据库查询语句时直接拼接了未经检查的用户输入数据。

举个例子：

假如我们有个sql语句：

select id,no from user where id=2;

如果该语句是通过sql字符串拼接得到的，比如：

String sql = “select id,no from user where id=” + id;

其中的 id 是一个用户输入的参数，那么，如果用户输入的是 2， 那么上面看到查到了一条数据，如果用户输入的是 2 or 1=1 进行sql注入攻击, 那么看到，上面的语句(select id,no from user where id=2 or 1=1; )将user表中的所有记录都查出来了。 这就是典型的sql注入。

比如在一个登录界面，要求输入用户名和密码：

可以这样输入实现免帐号登录：

用户名： ‘or 1 = 1 –

密 码：点登陆,如若没有做特殊处理,那么这个非法用户就很得意的登陆进去了.(当然现在的有些语言的数据库API已经处理了这些问题)

这是为什么呢? 下面我们分析一下：

从理论上说，后台认证程序中会有如下的SQL语句：

当输入了上面的用户名和密码，上面的SQL语句变成：

分析SQL语句：

条件后面username=”or 1=1 用户名等于 ” 或1=1 那么这个条件一定会成功；

然后后面加两个-，这意味着注释，它将后面的语句注释，让他们不起作用，这样语句永远都能正确执行，用户轻易骗过系统，获取合法身份。

常见的防范方法

（1）所有的查询语句都使用数据库提供的参数化查询接口，参数化的语句使用参数而不是将用户输入变量嵌入到SQL语句中。当前几乎所有的数据库系统都提供了参数化SQL语句执行接口，使用此接口可以非常有效的防止SQL注入攻击。

（2）对进入数据库的特殊字符（’”&*;等）进行转义处理，或编码转换。

（3）确认每种数据的类型，比如数字型的数据就必须是数字，数据库中的存储字段必须对应为int型。

（4）数据长度应该严格规定，能在一定程度上防止比较长的SQL注入语句无法正确执行。

（5）网站每个数据层的编码统一，建议全部使用UTF-8编码，上下层编码不一致有可能导致一些过滤模型被绕过。

（6）严格限制网站用户的数据库的操作权限，给此用户提供仅仅能够满足其工作的权限，从而最大限度的减少注入攻击对数据库的危害。

（7）避免网站显示SQL错误信息，比如类型错误、字段不匹配等，防止攻击者利用这些错误信息进行一些判断。

（8）在网站发布之前建议使用一些专业的SQL注入检测工具进行检测，及时修补这些SQL注入漏洞。

以上就是Snake的一些心得，希望本文的内容对大家的学习或者工作能带来一定的帮助，如果有疑问大家可以留言交流。