一种基于改进正则表示的SQL注入过滤模块设计

摘要：SQL 注入攻击作为利用应用系统的漏洞，进行Web应用服务攻击的方式之一，具有危害性大且实施简单的特点。该文在对SQL注入点分析的基础上，设计了一种针对不同注入点攻击采用不同的验证方法。对于可由用户编辑的注入点，采用改进正则表达式进行过滤，而对于不能被普通用户编辑的，采用哈希运算消息认证码机制来验证其完整性。实验表明，该设计具有较好的防范SQL注入的效果和较低的运行开销。

关键词：SQL注入攻击；注入点；正则表示

中图分类号：TP391 文献标识码：A 文章编号：1009-3044（2013）29-6639-04

1 概述

根据信息技术研究和分析企业 Gartner 公司的调查，目前75%以上的安全攻击都是针对应用的，而不是系统底层和网络。SQL 注入攻击作为利用应用系统的漏洞，进行Web应用服务攻击的主要方式之一，具有危害性大且实施简单的特点。来自应用程序安全测试公司Veracode的最新软件安全状况报告显示，三分之一的应用程序中仍然存在SQL注入漏洞。因此如何降低SQL注入攻击的风险，从根本上实施SQL注入攻击防御，成为当前Web应用安全面临的问题之一。该文从常见的SQL注入攻击和防御方法分析入手，对文献[1]中所提出的基于正则表示的Web服务端SQL注入过滤模块进行改进。通过测试分析，表明该方法是可行的，具有更好的性能和实用性。

2 SQL 注入攻击

SQL注入攻击是指攻击者利用Web应用程序中的注入漏洞，通过构造巧妙的SQL语句，和网页提交的内容结合起来向服务器端Web应用程序提交执行，以获取私密信息和非授权权限，进而达到攻击的目的。其攻击主要采用如下几种方式：

1）通过非法使用SQL语句攻击，如在注入点非法使用注释符号、存储过程或函数、union语句进行联合查询等攻击；

2）通过构造逻辑值为真或假的表达式进行攻击，如恒等式攻击（1=1），或在动态查询语句中构造逻辑值为假的表达式，然后利用服务器返回的错误信息推测相关数据库信息等；

3）使用 SQL 注入扫描工具攻击，如BSQL hacker、Safe3 SQL Injector等自动注入攻击软件。

目前防御SQL注入攻击的方法主要有以下几种：

1）基于监测SQL语句逻辑结构是否被更改的方法。即通过对互联网应用程序的源码进行分析，定位存在的 SQL 注入漏洞，并在运行时实时监控 SQL 注入漏洞是否触发来防御，如AMENSIA[2]和SQLGuard方法 [3]。这种方法针对SQL 语句的逻辑结构是否被更改这一本质特征进行防御，检测效果较好，但是实现起来适用性不强，且性能较差。

2）基于随机化编码的方法 [4]。此种方法是对程序源代码中包含动态SQL语句的关键词进行随机化编码，运行时再对编码后的SQL语句进行解码，如果解码失败则表明受到了攻击。这种方法的缺陷是需要修改源码，另外部署较为复杂。

3）基于污点跟踪技术的方法[5-6]。该方法是在程序运行时把外部不可信输入标记为一个污染数据，然后在程序执行过程中跟踪汅点数据的传播流向，以判断它是否会引发SQL注入攻击。其缺陷是在高度模块化的Web应用程序中实现上述过程比较困难。

4）基于数据过滤的方法[7]。该方法主要是通过对常见 的SQL 注入攻击分析，提炼攻击特征，然后在客户端与web 服务器之间部署的插件、硬件设备中采用基于特征识别的方式识别并阻断各种攻击，达到防御的目的。如Web应用防火墙、截断过滤器、应用入侵检测系统等。此种方法通用性较强，但对于大量无规律的SQL注入攻击行为检测效果较差，漏报和误报率较高。

文献[1]中对SQL 注入攻击特征通过正则表达式进行描述，然后在服务器端以此进行过滤。与通过关键词进行的传统过滤方法相比，攻击识别的正确率较高。但是其只对通过Get和Post方式提交的数据进行验证，并没有对以其它方式进行注入的攻击进行检验，为此本文对其加以改进，以进一步提高识别的准确率。

3 改进正则表示的SQL注入过滤模块设计

3.1 注入点分析

无论何种形式的SQL注入攻击，其首要步骤就是判断Web应用程序是否存在SQL注入漏洞，即寻找能够输入恶意参数的位置。在一个存在漏洞的Web 应用程序中，通常存以下几种注入位置：

1） 通过POST和GET方式提交的数据。Post方式提交的数据是指在Form表单中，当表单的method属性为POST时用户输入的数据，该数据作为表单的数据体， 放在http body中传递给服务器端。Get方式提交的数据是指添加在URL的后面， 并作为URL的一部分发送给服务器端的数据，如“http：//domain-name/page.asp？arg=value” 中“？”后部的数据。如果攻击者在URL地址栏或页面表单各参数域（Text、Radio等域）位置填充精心构造的恶意内容，然后以get或post方式提交，就有可能在和关系数据库进行交互时获得私密信息，或者直接篡改Web数据，这就发生了SQL注入攻击。

2） Web 应用程序使用的cookie。Cookie是由服务器端Web应用程序生成，并以文件的形式存储在客户端，用来识别用户身份并保持用户Http状态信息的一种技术。由于Cookie是存放在客户端并通过name/value的形式来验证用户的数据，很容易被攻击者修改为含有非法SQL语句的Cookie，而且服务器接受到cookie，一般不采取验证措施，这样就导致了SQL注入。

3） http 报文头部。是指Web应用程序中使用的Http头部字段域，它们是超文本传输协议中请求和响应的部分信息，定义了Http传输的操作参数。如果这些字段域未经过验证，就用来构建 SQL 语句，将导致 SQL 注入漏洞。例如X-Forwarded-For是Http头的一个字段，它被认为是客户端通过Http或者负载均衡器连接到web服务端获取源Ip地址的一个标准。下面是一个使用它的例子，代码如图1所示。

图1 某开放源码的Web应用程序PHP代码

由代码可知，ip地址是通过Http头X-Forwarded-For得到返回值，并通过preg_match方法来验证是否至少存在一个合法的ip地址。由于在使用SQL查询前Http-X-Forwarded-For 环境变量没有充分的验证，这也就导致了在SQL查询时，可以通过这个字段注入任意SQL代码。

3.2 过滤模块设计

通过上述分析可见，SQL注入的发生根本原因在于服务器端对客户端提交的数据没有进行充分验证，因此过滤模块的设计采取对于用户发送的Http 请求在送往Web应用程序之前检查其数据安全性。检查的内容包括通过POST和GET方式提交的数据，如Url地址中的动态查询参数部分和表单中提交的Text、password，以及复选框Radio、checkbox等参数域。对于Web应用程序使用的Cookie来说，由于其在服务器与客户端传递的数据是通过Http头部信息的传递来实现，其中服务器发给客户端的数据包含在在Web服务器响应头的（Response Header）Set-cookie报头中，客户端发给服务器的数据包含在客户端请求头（Request Header）的Cookie报头中，因此对Cookie数据的验证主要是通过对http头中这两个报头中的“name/value”数据进行完整性对照检验。对于Http头字段域信息的验证，主要是检查容易发生SQL注入的头字段域（如User-agent、Referer等字段域）的值中是否包含SQL注入特征。

模块对用户发送的Http 请求在送往Web应用程序之前验证其安全性， 处理步骤如图2所示。在处理过程中，其关键点主要在于以下三个方面如何解决：

1） SQL 注入点属性的获取

模块对于首次提交的 Http请求，需要获取以下内容：

1）url 地址。为了减少漏报，模块将url 地址中的不含动态查询参数部分与当前页面的请求时间作为URL参数键值对的名（name），即把不同时间下的同一Url下请求视作不同请求get方式提交的查询字符串部分作为该参数键值对的值（Value）。

2） cookie 内容。由于客户端的Cookie数据来自服务器响应头中的Set-cookie报头，所以首次获取的内容主要是Set-cookie报头中的“name/value”、“Expires/time”键值对，以及客户请求端IP地址和用于验证的SHA1值。其中SHA1的值按SHA1（name+value+客户请求端IP地址）计算。

3） form 表单中各个参数域及相应的属性约束。Form 表单内参数较复杂，可以分为不可编辑型、枚举型、文本型三种数据结构。在页面URL地址首次出现时，对于表单内的文本类型如Text、Password、Textarea等表单域，要获取这些可编辑表单域的name、type、value属性以及Value的约束信息，如readonly、disabled、maxlength 等。对于枚举类型的 SQL 注入点如Radio、Checkbox等表单域，要获取其对应的初始值，并将其枚举值的集合作为相应的静态属性约束记录下来，如name、type、[枚举值1，枚举值2，…]。对于表单中的Submit、Hidden等这些不能被用户编辑的参数域则不做处理。

4）Http头中的数据。主要是获取在Http头中容易发生SQL注入的头字段域名及其值，如扩展实体头中的X-Forwarded-For以及请求头中的User-agent、Referer等字段域的名和相应值

以上获取的各种数据记录在服务器端的XML文件中。对于不是首次提交的Http请求，由于已经获取了相应各种注入点处的数据，所以此时只需获取已记录的各种键值对（name/value）数据，并按照 name对应的value值，进行相应的检验。

2）特征匹配

特征匹配是指针对Url地址中的动态查询参数部分、Form表单中文本类型和枚举类型 参数域和Http头中的数据，检测用户输入的值是否符合恶意注入参数的特征。其中对于文本类型的表单域数据，首先检测用户的输入是否符合其先前记录的属性约束（如maxlength等），如符合则检查输入值是否与黑名单中的恶意特征规则相匹配。对于枚举类型的表单域数据，由于其数据取值的特点，只检测其取值是否在先前记录的枚举值的集合中。而对于Url地址中的动态查询参数部分和Http头中的数据则直接通过黑名单验证。黑名单的规则主要是由常见 SQL注入攻击行为恶意字符串的正则表达式组成。为了提高识别的准确度，在设计恶意字符串的正则表达式时，进行了改进，增加了对相应字符的大小写和十六进制形式检验。如利用恒等式的攻击语句“ 'or 1=1— ”，相应的正则表达式为：“＼s*（（＼x27）|（'））＼s*（（＼x6F）|o|O|（＼x4F））（（＼x72）|r|R|（＼x52））＼s*（＼d）＼s*（（＼x3D）|（=））＼s*（＼d） ＼s*（＼x2d＼x2d|—）”，其中＼s*表示零次或多次匹配任何空白字符，包括空格、制表符、换页符等；（＼x27）|（'）表示单引号或它的十六进；（（＼x6F）|o|O|（＼x4F））（（＼x72）|r|R|（＼x52））表示or的大小写以及它的十六进；（＼x3D）|（=）表示等号或它的十六进制。再如通过“exec”执行以“SP”或“XP”字母开始的存储过程进行攻击的正则表达式为：“＼s*（（＼x65）|e|E|（＼x45））（（＼x78）|x|X|（＼x58））（（＼x65）|e|E|（＼x45））（（＼x63）|c|C|（＼x43））＼s*（（＼x73）|s|x|（＼x78）|S|（＼x53）|X|（＼x58））p＼w+。”

3）验证完整性

验证完整性是指判断客户端的Cookie数据是否被恶意篡改。这里通过以SHA1为加密散列函数的哈希运算消息认证码机制来验证。具体实现步骤是：获取当前客户端请求头（Request Header）Cookie报头中的“name/value”，当前请求时间，以及客户请求端IP地址和用于验证的SHA1值。SHA1的取值方式按 SHA1（当前Cookie的name+当前Cookie的value+当前客户请求端IP地址） 计算，然后与先前记录的服务器端响应头中的Cookie SHA1取值比较，如不相等则表明内容被篡改。在对Cookie验证时，需注意的是要先通过对当前Cookie的请求时间和先前记录的Expire属性的取值进行判断，以确定其没有过期或被浏览器关闭，如其已过期或被浏览器关闭则不进行完整性验证。

4 实现及测试

4.1 实现

SQL注入过滤模块部署在Web服务器端，它在Web请求发往到Web应用系统之前验证其安全性。该模块在实际应用中就是实现一种特殊接口（如J2EE中的Javax.servlet.Filter， 中的System.Web.IhttpModule），在PHP中可以通过PHP的OuterIterator接口中的FilterIterator类或者PHP的Filter来实现。由于不同的Web平台下执行SQL命令的函数接口有所差异，为了验证本模块的设计，选取了基于J2EE的Web应用程序进行测试，因此本模块程序主要是实现Javax.servlet.Filter接口。模块包含两个功能：一是获取当前Web页面各注入位置处的数据，由名为Filter_obtain的过滤器实现；二是实时检查获取的数据中是否存在常见的SQL注入特征或被恶意篡改，由名为Filter_Check的过滤器实现。两个过滤器构成一个过滤器链，如图3所示，过滤器链中不同过滤器的先后顺序由部署文件Web.xml中的映射顺序确定。

4.2 测试

模块的测试包括两点：一是测试模块对常见SQL注入攻击行为的拦截能力，通过识别率、误报率和漏报率衡量；二是测试其对Web应用系统性能的影响，通过系统响应时间衡量。测试的软硬件平台为：CPU为Intel 2.8Ghz，2GB内存，fedora9系统；Web服务器：Apache Tomcat5 + Java1.6 +mySql5.0。测试对象为一开放源码并采用Java开发的论坛系统Jforum2.1.9，并在其基础上进行修改，构造了在“注入点分析”中提到的漏洞用以测试。测试数据不仅包含了常见的各类 SQL 注入攻击行为，还包含正确的输入集合，共计500条，其中95条为各种SQL注入攻击。

测试结果如表1和表2所示。表1表明过滤模块在改进正则表达式过滤规则集的情况下的拦截性能较好，而且随着所含规则条数的增加，其识别率更高，能有效地拦截常见的SQL注入攻击，但是其误报率也较高，这是因为虽然强规则集中的过滤规则多，正则表达式也更精巧，识别的SQL注入更多更准确，然而规则数量的增多，也让正常输入偶然匹配到规则的概率增大，因而产生较高的误报率，可见过滤规则的组织对过滤性能的影响至关重要。表2说明对于正常Web请求，过滤模块对web请求的平均响应时间延迟了20ms左右，而对于包含恶意攻击的Web请求，延迟时间有所增加，特别是在过滤规则增加时，这主要是由于对规则的遍历匹配处理对系统的性能产生了一定程度的影响，但是该影响总体上在可接受的范围内。

5 结束语

本文在对SQL注入点分析的基础上，设计了一种对不同注入点攻击进行不同验证的防御方法。该方法通过对用户发送的Web

请求在送往Web应用程序之前，对存在明显注入特征字符串的SQL攻击行为进行过滤，测试表明该方法能有效地拦截SQL注入攻击，而且性能基本满足要求。由于本过滤模块对具有明显攻击特征的SQL注入攻击具有较好的拦截效果，如何拦截没有明显攻击特征的SQL注入攻击，将是下一步研究的重点。

参考文献：

[1] 王伟平，李昌，等.基于正则表示的SQL注入过滤模块设计[J].计算机工程，2011，37（5）：158-160.

[2] W.G.Halfond，A.Orso.AMNESIA：Analysis and Monitoring for Neutralizing SQL-Injection Attacks[C]// In Proceedings Of the IEEE and ACM International Conference on Automated Software Engineering（ASE2005），USA：IEEE press，2005

[3] G.T.Buehrer，B.W.Weide，P.A.G.Sivilotti.Using Parse Tree Validation to Prevent SQL Injection Attacks[C]//In International Workshop on Software Engineering and Middleware （SEM），USA：ACM press，2005.

[4] S.W.Boyd，A.D.Keromytis.SQLrand： Preventing SQL Injection Attacks[C]// In Proceedings of the 2nd Applied Cryptography and Network Security （ACNS） Conference， USA：Springer， 2004.

[5] V.B.Livshits，M.S.Lam.Finding Security Errors in Java Programs with Static Analysis[C]//In Proceedings of the 14th Usenix Security SymPosium，USA： USENIX Association ，2005.

[6] A.NgUyen-Tuong，S.Guarnieri，D.Greene，et al.Automatically Hardening Web Applications Using Precise Tainting Information[C]//In Twentieth IFIP International Information Security Conference（SEC 2005），USA： Springer ，2005.

[7] M.Roesch.Snort： Lightweight intrusion detection for networks[C]//In Proceedings of the 13th Conference on Systems Administration（LISA-99），USA： USENIX Association，1999.