浅谈Web安全之SQL注入攻击与防护

Posted 2021-04-11 电力信息化

摘要：正如大家所熟知的，SQL注入攻击已经成为最常见的Web应用攻击手段。随着WEB2.0时代的到来，B/S架构被广泛应用，部分web程序在开发阶段违背了“数据与代码分离”的安全原则，导致了SQL注入攻击的发生。本文将对SQL注入的方法以及对应的防范措施做简单探讨。

关键词：SQL注入; Web; 数据合法性

  

一、前言 

2016年7月，Ubuntu官方论坛被黑客攻击，导致超过两百万用户数据泄露。官方在深入调查后发现是论坛插件Forumrunner存在SQL注入漏洞导致了安全事件的发生。 

除此之外，因为SQL注入漏洞被黑客盗取敏感数据的例子屡见不鲜。在OWASP（开放web应用安全项目）组织于二零一七年所公布的《OWASP Top 10 – 2017 RC1》中注入类攻击排名第一，其中SQL注入是其主要的注入攻击方式。 

SQL注入攻击不仅会导致敏感数据泄露，更严重者会被攻击者获得服务器的管理员权限，进而以此为跳板对内网进行二次渗透。 

SQL 注入是通过正常的web端口进行访问，通常防火墙都不会对 SQL 注入发出警报，如果不借助相关的安全防护设备（如：WAF）或安全防护软件，很可能被入侵很长时间都不会被发觉。 

本文采用mysql数据库为目标，主要探讨SQL注入的方法以及对应的防范措施。

 

二、SQL 注入产生的原因 

SQL注入产生的原因在于web应用在开发阶段违背了“数据与代码分离”的安全原则，从而导致未经验证和过滤的危险字符串被web程序识别为代码并执行，才让SQL注入攻击得以实现。

 

三、SQL 注入的分类及对应攻击方法 

本文将SQL注入按照服务器返回的响应情况来进行划分，主要分为以下几种类型： 

1. 基于错误回显的SQL注入 

基于错误回显的SQL注入即通过构造存在缺陷或与逻辑自相矛盾的SQL语句来测试服务器是否返回错误信息，以及返回什么样的错误信息，从而来判断是否存在注入点以及对应的数据库类型。简单的方法举例如下： 

正常的页面搜索如下： 

http://192.168.3.23/sql.asp?id=2 

构造的SQL测试语句为： 

http://192.168.3.23/sql.asp?id=2' 

使用此方法来测试SQL注入漏洞是否存在，若页面能返回具体的SQL错误信息，则证明存在SQL注入漏洞。 

2. SQL盲注 

盲注即在服务器没有错误回显的情况下完成的SQL注入攻击。由于缺少错误信息回显，攻击者就必须找到另一个方法来判断注入的SQL语句是否得到有效执行。 

最简单的SQL盲注方法方法是构造条件语句，根据返回页面是否发生变化来判断SQL语句是否得到执行。简单的方法举例如下： 

执行一个正常搜索的URL如下： 

http://192.168.3.1/search.php?id=2017 

构造盲注语句为： 

http://192.168.3.1/search.php?id=2017 and 1=2 

此语句执行后，如果页面返回错误或者空白那么说明注入语句执行成功，但为了确认注入存在，还需再次构造SQL语句进行验证： 

http://192.168.3.1/search.php?id=2017 and 1=1 

执行如上语句后，如果页面返回正常，则说明构造的条件“and”执行成功。那么就可以确定id参数存在注入漏洞了。 

上面的例子中 and 1=2明显是一个假命题，但web程序并不会将错误结果返回到页面上，可能会出现空白页或者链接被重定向到一个事先做好的错误页面上；而and 1=1恒为真，则应该返回正常页面。由此来验证SQL语句的执行情况，便可以判断出SQL注入漏洞是否存在。

 

3. 时间延迟SQL注入攻击 

在MySQL中，还存在一个BENCHMARK()的函数，原本用做函数性能测试，时间延迟攻击正是利用了该函数，让同一个函数执行若干次，导致函数返回结果的时间长于正常时间，通过执行时间的长短来判断构造的SQL语句是否执行成功。这是盲注的一个高级技巧，在不同的数据库中均有类似sleep() 函数和BENCHMARK()函数这样的函数，可以用来实现时间延迟SQL注入攻击。实现方法与盲注类似，这里就不再赘述。

 

四、SQL注入的防护措施探讨 

前文着重探讨了SQL注入的产生、分类与对应的实现方法。本章主要探讨SQL注入的有效防护措施。具体的防护措施归纳如下： 

1.校验输入的数据类型 

根据前面的分析和测试可知，在开发阶段即要有意识的将数据与代码分离开。将一切的用户输入均视为不可信的输入，统一对用户输入的数据类型进行校验。严格限制数据类型，并始终对输入的数据进行检查，过滤掉危险字符。 

2. 使用预编译的SQL语句 

在程序功能实现的过程中可以使用预编译的SQL语句，绑定变量，确保了语义的准确可信。攻击者无法改变SQL语句的结构和形态，从而有效对抗SQL注入。 

3. 使用较为安全的函数 

在开发阶段就使用OWASP推荐的安全函数，参考OWASP ESAPI中的部分功能实现进行开发。与此同时，目前主流数据库厂商均提供了安全函数编码参考和一些具体的存储过程，使用这些安全的函数来代替存在风险的函数和传统的SQL语句拼接。 

4. 落实数据库权限最小化原则 

在进行数据库权限规划和程序账号权限规划时，建议使用最小权限原则，避免web应用直接使用root、sa等高权限账户连接和操作数据库。同时web应用所使用的数据库账号不能拥有操作本地文件和创建自定义函数等高危权限。 

5. 尽可能使用存储过程 

在web应用规划阶段应对数据进行详细分析，尽量采用存储过程来代替SQL语句的拼接。由于存储过程需要在数据库中对SQL语句进行预定义，因此需要尽量避免在存储过程中使用动态SQL语句的情况，但存储过程仍然存在被注入的风险。 

6. 反复查找SQL注入漏洞并修复他们 

这是最原始也是最笨的解决方法，通过频繁的渗透测试将web应用中存在的SQL注入全部找出来，然后逐一修复他们。 

7. 采用安全防护硬件（WAF、数据库防火墙） 

目前诸多信息安全厂商均已推出相关的SQL注入和web应用安全防护产品，如：WAF、数据库防火墙等安全设备均可以在一定程度上对SQL注入进行防范，但基于安全规则的防护效果均不太理想。

 

五、总结 

本文对SQL注入的产生，SQL注入的分类以及各类型SQL注入的具体实现方法进行了介绍，对各类SQL注入的思路进行了分析梳理。希望能为信息安全技术人员、web开发人员提供一个相对可信的技术认知。文中加入了本人对SQL注入漏洞的防范心得，希望能共同探讨SQL注入漏洞的防范，提高企业信息安全防护能力。也希望能有更多的技术人员关注信息安全漏洞，共同提高信息安全防范意识，净化网络环境。

 

参考文献 

[1] [中].吴翰清.白帽子讲web安全.北京：电子工业出版社，2014, 152 

[2] [日].徳丸浩.Web应用安全指南.北京：人民邮电出版社，2014, 111 

[3] [美].Ferruh Mavituna.Deep Blind SQL Injection, 2008, 2 

[4] [美].David Litchfield,Chris Anley,John Heasman,Bill Grindlay.The Database Hacker's Handbook Defending Database Servers,北京：清华大学出版社, 2006, 33 

文山供电局  娄宇  简榕  高宇