基于敏感字符的SQL注入攻击防御方法

张慧琳 丁 羽 张利华 段 镭 张 超 韦 韬 李冠成 韩心慧

1(北京大学计算机科学技术研究所 北京 100080)2(加州大学伯克利分校 加利福尼亚伯克利 94720)3(百度美国有限责任公司 加利福尼亚森尼韦尔 94089) (zhanghuilin@pku.edu.cn)



基于敏感字符的SQL注入攻击防御方法

张慧琳1丁 羽1张利华1段 镭1张 超2韦 韬3李冠成1韩心慧1

1(北京大学计算机科学技术研究所 北京 100080)2(加州大学伯克利分校 加利福尼亚伯克利 94720)3(百度美国有限责任公司 加利福尼亚森尼韦尔 94089) (zhanghuilin@pku.edu.cn)

SQL注入攻击历史悠久，其检测机制也研究甚广.现有的研究利用污点分析(taint analysis)结合SQL语句语法分析进行SQL注入攻击检测，但由于需要修改Web应用程序执行引擎来标记和跟踪污点信息，难以部署，并且时间和空间性能损失过大.通过分析SQL注入攻击机理，提出一种基于敏感字符的SQL注入攻击防御方法.1)仅对来自常量字符串的可信敏感字符进行积极污点标记；2)无需修改Web应用程序执行引擎，利用编码转换将污点信息直接存储在可信敏感字符的编码值中，动态跟踪其在程序中的传播；3)无需SQL语句语法分析，只需利用编码值判断SQL语句中敏感字符的来源、转义非可信敏感字符，即可防御SQL注入攻击.基于PHP的Zend引擎实现了系统原型PHPGate，以插件方式实现、易部署.实验证明：PHPGate可精确防御SQL注入攻击，且有效提升污点传播效率，页面应答的时间开销不超过1.6%.

SQL 注入攻击；可信敏感字符；动态污点分析；积极污点分析；编码转换

SQL注入(SQL injection)是一种代码注入(code injection)攻击[1-2]，其根源是Web应用程序中的SQL语句通常由程序中可信的常量字符串和用户输入等不可信的外来数据动态拼接而成，而Web应用程序中存在输入验证漏洞，导致用户输入等不可信数据未经充分净化、过滤就被数据库引擎当作SQL代码片段执行.攻击者可以通过构造精巧的畸形输入，生成恶意SQL语句进入数据库执行，以此越权获取数据库中的数据，或通过数据库相关接口直接执行系统指令.

开放式Web应用程序安全项目组织(open Web application security project, OWASP)发布的Web安全威胁评估报告[3]显示，SQL注入攻击是当前最严重的Web安全威胁.SQL注入攻击泛滥的原因在于：首先，攻击原理简单、门槛较低，自动化攻击工具众多[4]；其次，攻击后得到的数据价值高，例如口令数据库、用户个人隐私等；最后，避免SQL注入漏洞需要在Web应用程序代码中缜密全面地对用户输入等不可信数据进行验证，或使用参数化查询、存储过程等来约束SQL语句语法结构[5-6]，但这种安全思维并不普遍存在于程序员群体[7-10].

研究人员基于污点分析来标识SQL语句各部分的来源，依赖SQL语句语法解析进行SQL注入攻击检测.主要分为3个步骤：1)污点标记，即对用户输入等不可信数据或可信的常量字符串设置污点标记(前者为消极污点标记negative taint，后者为积极污点标记positive taint)，其中，标记粒度通常在字符级别，即每个字符对应一个污点状态；2)污点传播(taint propagation)，即在程序执行过程中，对带有污点的字符串进行运算、移动操作时将污点标记传播到结果字符串的对应位置；3)污点检查，在SQL语句执行点(sink点)解析SQL语句语法结构，分析各部分(如关键词和操作符)的污点信息来检测SQL注入攻击.

现有的基于污点分析的SQL注入攻击检测方法在可部署性、检测性能、检测精度上均存在不足，难以实际应用：1)现有方案需要修改Web应用程序执行引擎，通过在String类中增加污点属性域来记录其中每个字符的污点状态，或在内存中专门分配一块空间，以字符地址为索引，以0,1为值来记录该字符的污点状态，污点标记及污点传播过程即是对这些属性域或内存空间的赋值与更新，该过程带来不少的额外空间占用和时间性能损耗，并且修改引擎的实现方式不便于实际部署；2)在Sink点检查时需对SQL语句语法分析[11-12]，检测的准确率依赖语法分析的精度[12-13]，并且语法分析本身也会带来一定的性能损耗[12].

本文提出了基于敏感字符的SQL注入攻击防御方法，无需修改Web应用程序执行引擎，无需依赖SQL语句语法分析，自动完成SQL注入攻击防御.主要贡献包括：

1) 分析SQL注入攻击机理，提出了敏感字符和SQL安全条件的概念.无需依赖SQL语句语法解析进行SQL注入攻击检测，仅对来自常量字符串的可信敏感字符进行污点标记和跟踪，在SQL语句中识别并转义来自不可信输入的非可信敏感字符，从而保证SQL安全条件、防御SQL注入攻击.

2) 无需修改Web应用程序执行引擎来标记和跟踪污点信息，提出了一种基于编码转换的轻量级污点标记及传播方法.利用编码转换将污点信息直接存储在可信敏感字符的编码值中，节约了污点信息的额外存储空间；污点信息随着字符串操作可直接传播到结果字符串，节约了污点传播的时间开销.该方法广泛适用于UTF-8编码的Web应用程序.

3) 整个方法实现为一个PHP插件——PHP-Gate，自动完成SQL注入攻击防御.无需修改Web应用程序执行引擎，方便部署.

4) 实验验证防御效果和性能损失.证明PHP-Gate可以高效进行污点传播、准确防御SQL注入攻击，且页面应答的时间开销不超过1.6%.

1 SQL注入攻击机理

Web应用程序将可信的常量字符串和用户输入等不可信的外来数据动态拼接出SQL语句.SQL注入攻击成功的本质在于控制结构(语法结构)和外来数据混合在同一传输通道中[6]，攻击者精心构造的输入没有仅作为查询值，而是破坏了约定的SQL语句的语法结构，导致输入数据作为未授权的SQL代码片段被执行.如图1中，攻击者构造图1②所示的参数值与图1①中的常量字符串拼接，从而在图1③中生成的SQL语句中注入了OR ′1′=′1′ 永真式条件.

Fig. 1 An example of SQL injection and detection methods based on taint analysis.图1 SQL注入攻击实例与基于污点分析的检测示例

图1中④⑤展示了现有的消极或积极污点分析方法的污点检查流程(图1④中虚线框中为带有消极污点标记的部分，图1⑤中实线框为带有积极污点标记的部分)：1)解析SQL语句；2)发现OR ′1′=′1′条件语句含有消极污点标记或者不含积极污点标记，即检测出未授权的SQL代码片段(图1④⑤中阴影部分).

进一步分析图1的SQL注入攻击实例，SQL注入攻击分为2步：

1) 闭合当前语法结构，通过注入单引号′来闭合name查询值；

2) 引入新的语法结构，通过OR ′1′=′1与常量字符串中的单引号′拼接来构造永真式条件.

在该实例中，攻击者精心注入引号、空格、等号等分隔符，使生成的SQL语句的语法和语义发生了变化.

本文的SQL注入攻击防御方法基于2种现象：

1) SQL文法是上下文无关文法.其语法被一些语法相关字符(如空格、分号、引号等)所控制、约束；

2) 数据库引擎最终执行安全的SQL语句的语法和语义应与Web程序开发时所约定的语法和语义一致.其充要条件为：最终执行的SQL语句中，所有的语法相关字符一一对应于Web程序开发时内置的常量字符串中的语法分隔符.

上述条件保证SQL语句的语法结构未被攻击者篡改.由于SQL注入攻击并不改变Web程序自身的执行逻辑，且不能更改常量字符串中语法相关字符及其顺序，因此上述条件放宽为：SQL语句中所有的语法相关字符都来自于常量字符串，也可以保证无SQL注入攻击发生.我们称之为“SQL安全条件”.

2 方法设计及关键点

为了便于后文描述，首先进行下述定义：

定义1. 敏感字符. SQL文法定义中，对SQL语句的语义和语法结构敏感的字符①在SQL语句中，敏感字符既可以作为语法相关字符(如图1中攻击者输入的空格)，也可作为普通字符(如图1示例中，若用户输入“张 三”，其中的空格即为普通字符).

定义2. 可信敏感字符和非可信敏感字符. 按照字符的不同来源，将敏感字符分为可信敏感字符和非可信敏感字符：可信敏感字符为来自Web应用程序常量字符串的敏感字符；非可信敏感字符为来自不可信输入的敏感字符.

基于上述定义，结合SQL安全条件，分析如下：

1) 如果SQL语句中的敏感字符全部为可信敏感字符，即全部来自可信的常量字符串，则可推出该SQL语句中的语法相关字符也一定全部来自常量字符串，符合SQL安全条件，不存在SQL注入攻击.

2) 如果SQL语句含有来自不可信输入的敏感字符，则这些敏感字符可能被数据库引擎解析为语法相关字符，破坏SQL语句的语法结构，导致SQL注入攻击.为了保证SQL安全条件，避免非可信敏感字符作为SQL语句的语法相关字符，可利用数据库引擎特有的转义特性，在这些非可信敏感字符前添加转义符，实现SQL注入攻击防御.

3) 为了区分SQL语句中敏感字符的来源，对常量字符串中的敏感字符进行积极污点标记(见2.1节、2.2节)，使用编码转换的方式将污点信息直接存储在字节值中(见2.3节)，在程序动态执行过程中进行污点传播，将污点标记传播到生成的SQL语句中.

基于敏感字符的SQL注入攻击防御方法如图2所示：在污点标记时，将标记对象(taint source)限定为常量字符串中的敏感字符(示例中的实线框部分)，对其进行编码转换；污点传播过程与程序对可信敏感字符的操作相伴；污点检查过程则在SQL语句被送往数据库引擎执行前，将可信敏感字符恢复为标准编码，在非可信敏感字符前添加转义符(本文以反斜线为例).

Fig. 2 SQL injection prevention based on sensitive characters.图2 基于敏感字符的SQL注入攻击防御方法设计

该方法可成功防御SQL注入攻击.图2的示例中，数据库引擎将字符串中的和随后字符当作一个转义序列，和单引号、空格、等号的组合被认作转义序列，数据库引擎将在test表中查找name为1′ OR ′1′=′1的记录，成功防御SQL注入攻击.

该方法不会影响用户与Web应用程序、数据库引擎的正常交互.图2的示例中，若用户输入“张 三”(中间含有非可信敏感字符——空格)，经过处理后的查询条件变为WHEREname=′张 三′，数据库引擎将字符串中的和随后空格当作一个转义序列，仍将在test表中查找name为“张 三”(中间含有空格)的记录.

2.1 敏感字符集

常见的SQL敏感字符有单引号、分号、破折号、反斜杠、@、星号等.若要达到完备的SQL注入攻击防御效果，敏感字符集应该包括所有能够改变SQL语句的语法和语义的字符.通过对大量SQL注入攻击的实例分析，逐一排查ASCII字符，可以得到33个字符，再另外加上SQL语句接受的换行符、回车符、制表符3个空白符，构成容量为36的敏感字符集合，如表1所示.

表1的敏感字符是完备的：不包含SQL不接受的空白字符、非可见字符以及表1中敏感字符的字符串，只能由大小写字母、数字以及中文、韩文等组成，这样的字符串并不能引起SQL语句在语法和语义上的变化，攻击者无法通过注入这样的字符串来实现SQL注入攻击，进而越权读取数据、越权执行命令.

Table 1 Sensitive Characters and Their Encodings

2.2 积极污点标记可信敏感字符

对敏感字符的污点标记分为2种方式：对常量字符串中的可信敏感字符设置积极污点标记和对不可信输入中的非可信敏感字符设置消极污点标记.本文采用积极污点标记方式，其优点在于：实际系统中，不可信输入来自于诸多渠道参数，并没有一个简单、可用的接口来对所有不可信输入进行标记，消极污点标记难以将所有的非可信敏感字符都标记为污点数据；而可信数据以常量字符串形式存在，对Web程序常量字符串中的可信敏感字符进行积极污点标记后，所有非可信敏感字符则会以未标记的形式存在，标记结果更加准确.

2.3 编码转换方式记录污点状态

现有的污点标记及传播模型需要Web应用程序执行引擎修改String类数据结构或者额外分配内存空间来记录污点信息，由于性能损耗较大而难以得到实用.

本文利用UTF-8编码特性，通过编码转换来记录污点状态，通过编码值来区分可信敏感字符和非可信敏感字符.该方案减少了污点标记和传播的空间和时间开销：把需要标记的字符的字节值转换为不符合UTF-8 编码规则的字节值，编码转换之后的字节值自带污点信息，无需额外分配空间记录污点信息；污点传播时，污点信息可被字符串操作自动传播到结果字符串的相应位置；污点检查时，只需扫描字符串，找到非标准的UTF-8 编码字节即为污点字符.方法属于一种轻量级的污点标记及分析方法，并且适用于所有UTF-8编码的Web程序.

UTF-8编码是Unicode字符集(U+0000～U+FFFF)的一种编码方式.对于字符U+0000～U+007F，UTF-8与基本ASCII编码方案一致，采用一个字节表示(二进制表示为0xxxxxxx)；对于之后的Unicode字符，UTF-8采用2～4个字节表示，其中首字节由n位连续的1加1位0开始(n为字符编码所需的字节数)，其后的每个字节的最高2 b固定位为“10”.例如3 B字符的UTF-8编码结构为“1110xxxx 10xxxxxx 10xxxxxx”，其中掩码部分即Unicode字符的序号.

由于表1中的敏感字符在UTF-8编码中均是单字节字符，而UTF-8单字节字符编码规则中存在形如1xxxxxxx(0x80-0xFF)的“编码空洞”.在标准的UTF-8编码字节流中，形如10xxxxxx的字节一定是多字节字符的后续字节，而不会是单字节或多字节字符的首字节.根据UTF-8编码的上述特性，在单字节字符编码空洞10xxxxxx中为可信敏感字符划分出编码空间，使用编码转换的方式进行污点状态记录：即在污点标记阶段，将常量字符串中的可信敏感字符的UTF-8编码字节值一一转换为0x80-0xA3这些特殊的“非法”编码字节值，具体的编码转换映射关系如表1所示.这些非标准UTF-8编码的单字节自带污点信息，且可以在程序执行中自动传播到结果字符串中，并能与以0xxxxxxx原编码形式存在的、未被污点标记的非可信敏感字符进行区分.

对可信敏感字符的编码转换并没有为UTF-8解码带来二义性：本文只用了部分UTF-8单字节字符编码“空洞”(0x80-0xBF)，即被标记的可信敏感字符具有形式“10xx xxxx”.在标准的UTF-8 编码中，“10”开头的字节不会存在于字符的首字节，而在解码带有污点信息的UTF-8字节流时，若一旦遇到首字节就为“10xxxxxx”形式，则该字符一定是经过编码转换后的可信敏感字符.对可信敏感字符的编码转换没有使用编码空洞的另一部分(0xC0-0xFF，具有形式“11xxxxxx”，其可能会是多字节字符的首字节)，不会引起UTF-8解码的二义性.

3 方法描述

第2节提出将可信敏感字符的字节值转换为非标准UTF-8编码值，这种基于编码转换的污点状态记录方式，广泛适用于采用UTF-8编码的Web应用程序.

本文的污点标记、污点传播、污点检查过程分别对应着UTF-8字节流的编码转换、字节值操作以及编码检查过程.本节详细描述各个过程，为了便于后文描述，首先阐述下述定义.

定义3.C为UTF-8标准编码的全集，具体分为4类：

1) 单字节字符，编码字节为

0xxxxxxx；

2) 2个字节字符，编码字节为

110xxxxx 10xxxxxx；

3) 3个字节字符，编码字节为

1110xxxx 10xxxxxx 10xxxxxx；

4) 4个字节字符，编码字节为

11110xxx 10xxxxxx 10xxxxxx 10xxxxxx.

定义4.SC为所有敏感字符的UTF-8编码集合.SC中共36个元素，均为单字节编码，具体如表1所示(形如0xxxxxxx).

定义5.SSC为非标准的单字节字符编码，共36个元素，值为10000000～10100011 (均具有形式10xxxxxx)

定义6. 编码转换map将SC中的标准编码一一映射到SSC中的非标准编码，具体的映射关系如表1所示，定义如下：

map:SC→SSC，

ε∈SC⟹map(ε)∈SSC，

ε∈SC∧γ∈SC∧γ≠ε⟹map(γ)≠map(ε).

定义7. 编码恢复remap将SSC中的非标准编码还原为SC中的标准编码，具体的映射关系如表1所示，定义如下：

remap:SSC→SC,

ε∈SSC⟹remap(ε)∈SC,

ε∈SSC∧γ∈SSC∧γ≠ε⟹remap(γ)≠remap(ε).

上述定义具有4个性质：

性质1.SC⊆C.

性质2. 不可伪造性.SSC∩C=∅使非标准编码与标准UTF-8编码完全区分，即非标准编码不能被UTF-8标准编码伪造.

性质3. 编码转换map具有编码唯一性，即：

∀ε∈SC∧∀γ∈SC∧γ≠ε⟹map(γ)≠map(ε).

性质4. 编码恢复remap具有解码唯一性，即：

∀ε∈SSC∧∀γ∈SSC∧γ≠ε⟹

remap(γ)≠remap(ε).

3.1 基于编码转换的污点标记

算法1完成对可信敏感字符的积极污点标记.

算法1. 污点标记算法TaintSC.

输入：UTF-8常量字符串的集合ConststringSet;

输出：编码转换后的常量字符串集合.

① for eachQinConststringSet：

② character_listcl=utf8_standard_decode(Q);

③ for eachμincl:

④Mark(μ);

⑤ end for

⑥ end for

步骤①遍历Web应用程序中常量字符串的集合ConststringSet，选定一个UTF-8常量字符串，其字节流为Q.

步骤②对Q进行UTF-8标准解码.即按照C的编码集合，对Q进行划分，划分出1个字节组序列cl，其中每个字节组含有1～4个字节，对应着1个UTF-8字符.

步骤③遍历步骤②中字节组序列中的每个UTF-8字符.

步骤④对每个UTF-8字符，用定义8中的函数Mark将敏感字符的标准编码字节值转换为非标准编码字节值，其他字符的编码字节值则保持原样.

定义8. 函数Mark：

Mark:C→SSC∪{C-SC},

(1)

污点标记算法TaintSC完成了对常量字符串中可信敏感字符的标记，可信敏感字符的编码字节值均被SSC中的非标准编码字节值替换，常量字符串中其余字符则保留原编码字节值，被标记后的常量字符串的编码空间为SSC∪{C-SC}.

3.2 基于编码转换的污点传播

Web应用程序常量字符串中的可信敏感字符经过TaintSC算法被转换为SSC中的非标准编码字节值，而用户输入等不可信数据中的非可信敏感字符则以SC中的标准编码形式存在.程序执行时，将二者混合在一起操作，字符串的编码空间为SSC∪C.

污点传播要求在字符串操作中跟踪、存储和更新结果字符串中相应的污点信息.可信敏感字符以编码转换的方式在字节值中自动携带污点信息，污点传播过程与程序对可信敏感字符的操作相伴.字符字节值中自动携带的污点信息会随着程序执行自动传播，不需要额外的跟踪算法.但是，由于污点标记后的字节流不符合标准UTF-8编码规则，程序中的字符串函数需分为3种情况进行处理：

1) 拼接、分割类函数

该类函数(如join,substr等)对字符串参数做拼接、分割处理.编码转换的污点标记方式并不改变字符串长度和字符位置，因此无需对这些函数进行额外处理，参数中可信敏感字符的非标准编码字节可随着函数执行自动赋值到结果字节流中相应位置.

2) 数值操作类函数

该类函数如md5等，直接对整个字符串取值后进行字面值操作.对于这类函数，在函数执行前需对参数中的可信敏感字符进行编码恢复(即污点净化)，从而保证得到正确的函数执行效果.

3) 含有字符匹配逻辑的函数

该类函数分为2个步骤：首先通过字符(串)匹配逻辑确定操作位置；然后在此位置上对字节流进行增(如addcslashes函数增加反斜线)、删(如trim函数删除指定字符)、改(如replace函数用指定字符串替换)等操作.

字符匹配过程中，由于编码转换的污点标记方式使每个敏感字符根据是否来自常量字符串存在2种字节值，所以需对该逻辑进行修改：若2个字符α,β(无先后顺序)满足式(2)所述条件，则认为二者匹配：

(α,β∈C∧α=β)∨(α,β∈SSC∧α=β)∨

(α∈SC∧β∈SSC∧α=remap(β)).

(2)

而增、删、改操作会自动将参数中的污点标记赋值到结果字节流中相应位置，实现污点的自动传播，所以无需做额外处理.

3.3 基于编码转换的污点检查

在SQL语句传入数据库引擎执行前，分析SQL语句的UTF-8字节流，进行污点检查，检查SQL语句中所有的敏感字符是否都带有污点标记(SSC中的编码形式，即可信敏感字符)以及是否存在未带有污点标记的敏感字符(SC中的原编码形式，即非可信敏感字符)，算法如下：

算法2. 污点检查算法SQLCheck.

输入：动态拼接出的SQL语句，其字节流为Q；

输出：编码恢复后的SQL语句字节流，非可信敏感字符的下标集合UntrustIndex.

①UntrustIndex∅;

② character_listcl=utf8_extended_decode(Q);

③ for eachμincl*μ∈{SSC∪C}*

④ ifμ∈SSC

⑤remap(μ);

⑥ end if

⑦ ifμ∈SC

⑧UntrustIndex.add(μ.index);

⑨ end if

⑩ end for

步骤②对Q进行UTF-8扩展解码.即按照SSC∪C中的编码集合对Q进行划分，划分出1个字节组序列cl.其中每个字节组含有1～4个字节，对应着一个UTF-8字符或带污点标记的可信敏感字符.

步骤③遍历步骤②中字节组序列中的每个字符μ.

步骤④～⑨对步骤③的每个μ，将可信敏感字符(μ∈SSC)的非标准编码字节值恢复为标准编码字节值，非可信敏感字符的编码字节值(μ∈SC)则保持原样，将其下标加入UntrustIndex中，对于μ∈{C-SC}的字符，字节值保持原样.

3.4 SQL注入攻击自动防御

经过SQLCheck算法的处理，SQL语句中的可信敏感字符已经恢复为标准的UTF-8编码字节值，整个SQL语句为标准的UTF-8编码.通过算法3完成SQL注入攻击的自动防御.

算法3. SQL注入攻击自动防御算法SQLIn-jectionPrevention.

输入：SQLCheck处理后的SQL语句字节流Q以及非可信敏感字符的下标集合UntrustIndex;

输出：在非可信敏感字符前添加转义符，执行SQL语句.

① ifUntrustIndex=∅；

② SQL_exec(Q);

③ else

④ for eachiinUntrustIndex

⑤ prepend ‘’ beforeQ[i];

⑥ end for

⑦ SQL_exec(Q);

⑧ end if

步骤①～②若发现UntrustIndex=∅，则说明SQL语句中不含有非可信敏感字符，SQL语句中的敏感字符全部来自可信的字符串常量，该SQL语句符合SQL安全条件，不存在SQL注入攻击，被直接送往数据库执行.

步骤③～⑦若UntrustIndex≠∅，则SQL语句含有来自不可信输入的敏感字符，这些非可信敏感字符可能破坏SQL语句语法结构，造成SQL注入攻击.在这些非可信敏感字符前添加转义符来自动防御SQL注入攻击(由于添加转义符会使SQL语句长度发生变化，步骤④～⑥仅表示抽象逻辑).

4 PHPGate系统实现

针对PHP语言进行原型系统实现.本文的方法无需修改PHP执行引擎源码，而是将上节所述方法实现为PHP执行引擎的一个插件——PHP-Gate.插件的实现方式较易部署，同时PHP执行引擎是C语言编写，插件也是C语言编写，执行效率高.

在一个典型的Web服务器中，PHP程序被执行引擎——Zend解释执行.如图3实线方框所示，过程分为2步：首先，生成中间码(byte codes)，其中，PHP程序中的常量字符串被解释为中间码的参数；然后，执行中间码，执行时调用相应的处理函数(handler)完成功能.

Zend引擎提供了完整的插件开发API，使开发者可以在PHP解释、执行过程中插装代码，监控并操作应用层代码的执行细节.如图3虚线方框所示，PHPGate通过遍历中间码及其参数实现污点标记，通过对Zend引擎中一系列函数的hook实现污点传播、污点检查.

Fig. 3 PHPGate implementation and working process.图3 PHPGate系统工作流程

4.1 可信敏感字符标记

可信敏感字符的污点标记包括2个步骤：常量字符串提取和可信敏感字符编码转换.常量字符串提取负责从中间码的参数中找到常量字符串.可信敏感字符编码转化则将常量字符串中敏感字符的标准编码字节值转变为表1中的非标准编码字节值.

PHPGate通过Zend引擎中zend_compile_file函数实现常量字符串提取和可信敏感字符编码转换.Zend引擎通过zend_compile_file函数把PHP程序解释成一系列中间码，PHPGate通过插件的相应接口hook该函数，在中间码生成后遍历所有的中间码，检查每一条中间码的参数：如果参数类型为字符串且具有属性IS_CONST，则该参数为PHP程序中的常量字符串，按照3.1节所述的TaintSC算法完成可信敏感字符编码转换.

4.2 污点传播及净化的实现

1) 内置字符串函数

PHPGate对PHP内置字符串函数的handler进行hook，按照3.2节所述的3种不同分类分别实现无操作、参数污点净化(即编码恢复)以及重定义字符匹配逻辑.

2) 特殊的中间码

可信敏感字符的编码转换改变了一些中间码参数的字节值，为了保证程序正常逻辑不被破坏，还需要对下述5个中间码进行参数净化处理:

ZEND_INCLUDE_OR_EVAL, ZEND_ECHO,

ZEND_PRINT, ZEND_DO_FCALL_BY_NAME, ZEND_DO_FCALL.

前3条中间码在执行时无法处理可信敏感字符的非标准编码形态，PHPGate修改它们的handler，使之指向一个wrap函数.wrap函数首先对中间码的字符串参数进行污点净化，将可信敏感字符编码恢复；接着调用原来的handler完成操作；最后在handler执行完后将参数中的可信敏感字符重新编码转换为污点形态(污点重标记)，保证污点的正确传播.

后2个中间码的语义为根据参数指明的函数名查找对应的内置函数.如果这2个中间码的字符串参数(即函数名)中包含非标准编码，也会引起逻辑错误，导致找不到所调用的函数，所以也需对参数进行污点净化及污点重标记.

4.3 污点检查及SQL注入攻击防御的实现

在SQL语句送入数据库引擎前，需要对所有的敏感字符进行检查：对于污点形态的敏感字符，需要编码恢复；对于正常形态的敏感字符，需要进行相应处理，如在其之前加入‘’字符使其失去改变SQL语义的功能.

与hook内置字符串函数的方式类似，PHP-Gate对数据库操作函数指定了一个新的handler，实现 SQLCheck算法和SQLInjectionPrevention算法.最后将处理过的SQL语句传给数据库引擎执行.

4.4 伪标记问题的处理

4.1节至4.3节实现的SQL注入攻击防御方案基于一个前提：程序接受的用户输入都是UTF-8标准编码的字符串，即用户无法输入非标准UTF-8单字节.在PHP运行过程中会遇到类似md5等的Hash函数，这些Hash函数会产生任意字节值.这些字节可能会被解释为可信敏感字符，为了避免对这样的字节进行污点净化，PHPGate在所有的净化过程中对字符串加入UTF-8扩展解码合法性检查.如果字符串不是一个合法的扩展UTF-8编码字符串，则不对这个字符串进行污点净化操作.

4.5 性能优化

4.1节至4.4节实现的PHPGate可以保证逻辑正确运行，但是性能有待优化.

在类似ZEND_ECHO的参数污点净化和污点重标记处理中，如果反复申请内存以保存字符串的污点标记形式又在之后释放，将引起很大的性能开销.

PHPGate使用一种基于栈的方法来优化.PHPGate维护一个额外的“标记栈”来辅助污点净化、污点重标记.标记栈的运行和参数污点净化、污点重标记过程同步.每当PHPGate进行污点净化操作时，PHPGate向标记栈压入额外信息，额外信息包括每个参数的:

1) 各个污点字符下标；

2) 字符串指针；

3) 污点字符数.

最后，将参数数目压栈.

如“”，2个单引号在污点标记过程中被编码转换为0x8A；在执行ECHO时，PHPGate会先对参数进行污点净化，同时在标记栈依次压入5和7(参数字符串中污点字符下标)、字符串参数指针、2(污点字符数为2)、1(参数数目为1).在ECHO操作执行后，PHPGate依据标记栈上弹出的信息直接对参数字符串中的可信敏感字符进行污点重标记，避免了多次申请内存来分别保存污点净化和污点重标记前后的字符串参数.

5 实验与分析

为了测试PHPGate对SQL注入攻击的实际防御效果以及带来的性能损失，搭建了LAMP(Linux,Apache,MySQL,PHP)框架，其中：操作系统版本为Debian Linux 7，Linux内核为3.2.0-4-amd64，Apache版本为Apache 2.2.24，MySQL版本为5.5.35，PHP版本为 5.4.21.

防御效果测试中，一方面使用一个已有的SQL注入攻击测试集T；另一方面重现了针对知名PHP应用程序的SQL注入攻击，观察开启PHPGate之后攻击是否成功.

性能测试中，首先采用Zend自带的2个测试集：ZendBenchmark(bench.php)和PHP Benchmark Script测试PHPGate在不同类型操作中的性能损失；其次，测试SQL注入攻击测试集T的页面应答时间开销；最后，针对真实页面测试PHPGate的页面应答时间开销.

5.1 防御效果实验及讨论

1) 防御测试集T中的SQL注入攻击

选取了文献[8]和文献[12]的SQL注入攻击测试集T，如表2所示，包含3个PHP应用、19个SQL注入漏洞及攻击.实验表明，PHPGate能有效防御这19个SQL注入攻击.

Table 2 Effectiveness of SQL Injection Prevention on

表3选取了其中的2个SQL注入攻击实例，描述PHPGate对SQL注入攻击的防御效果(下划线为用户输入).示例1中，MySQL数据库引擎将反斜线和其后字符当作转义序列，查找值为junk″ or 1=1--的记录，从而成功防御了SQL注入攻击.示例2中，反斜线未在字符串中，MySQL数据库引擎将反斜线和其后字符当作2个独立字符，SQL语句语法解析失败后无法执行，从而阻止恶意SQL语句的执行，防御SQL注入攻击.

Table 3 Demonstration of SQL Injection Prevention

2) 防御真实SQL注入攻击案例

从ExploitDB[14]选择了5个公开的针对PHP应用的SQL注入攻击样本，安装相应版本的PHP应用，搭建实验环境并且模拟攻击.

表4列举了这5个攻击样本所针对的漏洞编号和应用名称.实验表明:PHPGate能有效防御这5个SQL注入攻击.

3) 防御能力对比

PHPGate不依赖SQL语句的语法分析进行攻击检测，避免了由于语法分析策略精度不够造成的漏报.对于图4中的SQL注入攻击样例(下划线为用户输入)，文献[13]中的语法分析策略不能准确检测出SQL注入攻击，而PHPGate通过转义SQL语句的非可信敏感字符，成功防御SQL注入攻击.

Table 4 PHPGate Prevent SQL Injection Attacks in the Wild

SELECTnameFROMaccountWHEREid=exit()

Fig. 4 A case of SQL injection.
图4 一个SQL注入攻击样例

4) PHPGate局限性

下划线_和百分号%是SQL语句的通配符，MySQL数据库引擎仅在Like匹配语句中才将字符串中的\_和\%当作转义序列.因此，PHPGate在处理非可信的_和%时，需要使用辅助手段(如SQL语句语法分析)来判断它们所在的语法结构并予以相应处理.

5.2 PHPGate性能测试

1) Zend测试集的性能测试

图5展示了针对ZendBenchmark的性能测试结果.横坐标为18个测试例，柱状图(左坐标轴，单位为秒)显示了在关闭和开启PHPGate的2种情况下运行时间的差别，深色柱为不加载PHPGate时的运行时间，浅色柱为开启PHPGate的运行时间，折线图显示了开启PHPGate后性能损失随不同测试例的变化曲线(右坐标轴).可以看出，在simplecall,strcat(200000)和simpleucall这3个测试例上PHP-Gate的损失较大，分别为5.84%,10.91%和11.21%，而在其他测试例上的性能损失均小于2%.此外，有些结果的性能损失为负数并不能说明开启PHPGate后运行速度比关闭时更快，而是说明PHPGate在这些操作上的性能影响小于系统影响、外界环境影响.

Fig. 5 Overhead on ZendBenchmark.图5 ZendBenchmark性能损失

Fig. 6 Overhead on PHP Benchmark Script.图6 PHP Benchmark Script性能损失

图6的PHP Benchmark Script从数学运算、字符串操作、循环和分支4个方面对PHPGate的性能进行测试.图6展示了针对PHP Benchmark Script的测试结果.可以看出，字符串操作测试例上PHPGate的损失较大，但仍在可接受的范围内(12.76%)，在其他测试例上的性能损失均很小.

表5对比了PHPGate与WASP[11,15]在同类型字符串操作函数的性能损失.WASP对Java中String类重新进行封装，在新增的属性域中存储每个字符的污点信息，污点传播需要对参数污点属性域逐一遍历，并按照污点传播策略对结果字符串的污点属性域逐一赋值.该过程对性能损失影响较大，实验数据表明，WASP在字符串相关操作上的性能损失从125%～7100%不等.而本文的基于编码转换的污点状态记录方式，污点信息直接存储在字节值中，随着字符串操作直接赋值到结果字符串中.对比看出，本文的污点标记及传播方法有效降低了字符串操作函数上的性能损失.

Table 5 Overhead Comparison of Two Methods on String

Manipulation

表5 字符串操作性能比较

2) 测试集T上的性能损失及比较

选取了文献[12]的SQL注入攻击测试集T，使用脚本在服务器本机对Web应用的首页发送访问请求，然后分别统计加载和不加载PHPGate的应答时间.由于在服务器本机进行测试，网络延迟可以忽略不计，而且网络延迟在PHPGate关闭和开启的情况下可以认为一致，不影响测试结果.对每个页面进行了50次请求，然后统计应答时间的平均值以及时间损耗.

表6列出了测试集T中Web应用的代码规模(line of code, LOC)以及使用PHPGate带来的性能损失，对比列出了文献[12]的性能损失.

Table 6 Overhead Comparison on Benchmark T

diglossia[12]使用污点分析结合SQL语句语法分析进行SQL注入攻击检测.表6中的列3和列4显示了diglossia[12]在污点标记、传播中带来的性能损耗以及加上SQL语句语法解析带来的性能损耗.可以看出：一方面，diglossia[12]的污点分析在测试集T上带来了一定的性能损耗；另一方面，SQL语句语法分析影响了diglossia[12]在测试集T上的性能.

在测试集T上，PHPGate的性能损失几乎为0：一方面在于测试集T中的页面相对简单，字符串操作较少，并且PHPGate是轻量级的污点标记及传播方案(如表5所示)；另一方面，PHPGate无需依赖SQL语句语法解析，直接转义非可信敏感字符进行SQL注入攻击防御.

3) 真实页面的性能损失

在使用测试集进行性能测试之外，还针对真实页面对PHPGate进行性能评估.使用Python脚本在服务器本机对测试页面以POST方式发送登陆请求，然后统计应答时间.对每个页面进行了10 000次请求，然后统计应答时间的平均值.表7展示了使用PHPGate前后页面访问服务器应答时间的测试结果.可以看出，页面访问的应答时间增加比例均在1.6%之内.

Table 7 Overhead on Popular Web Applications

6 相关工作

围绕SQL注入攻击防御的研究一直在持续进行[16-18].研究人员尝试根据一定的策略来推理出SQL语句中的可信和不可信部分[19-22]，这种方式依赖于推理策略的完备性，准确性不能得到保证.而基于污点分析的方案能通过污点标记、污点传播直接、准确地区分SQL语句中的可信和不可信部分，相对比较可靠，主要分为静态污点分析和动态污点分析2种.

静态污点分析中，Jovanovic等人提出的Pixy[23]采用流敏感、过程间和上下文敏感的静态数据流分析方法来挖掘Web应用漏洞.Livshits和Lam[24]利用静态数据流分析技术检查经过标记的用户输入是否到达SQL语句执行点，以此来挖掘SQL注入漏洞.Wassermann和Su将SQL语句构造过程抽象为一个上下文无关文法，用静态污点分析方法判断该文法中的非终止符是否与用户输入相关[25].Dahse 和Holz采用静态污点分析方法挖掘二阶式注入漏洞[26]，更进一步利用对900多个PHP内置函数的分析和模拟来进行更精确的静态污点分析[27].但由于静态污点分析方法无法很好地处理Web应用程序语言的动态特性，所以会引入较高的漏报，加上其需要保守式的程序分析，所以也会带来较多的误报.

动态污点分析方法则能更好地应对程序的动态特性：Nguyen-Tuong等人[28]修改PHP引擎中String类的数据结构和函数操作，在字符级别对不可信数据进行污点标记与传播，在Sink检查点分析SQL语句的语法结构，不允许SQL敏感字符和关键字来自不可信数据.Pietraszek和Berghe的CSSE[29]则是在PHP引擎中使用一个以变量指针为索引、以bitmap为值类型的查询表来实现对不可信数据逐字符的污点标记.Xu等人[30]基于C语言代码的自动转换，动态维护了一个以单个字节的地址为索引、以0或1为值的查询表，通用地对C语言程序增强了污点标记与跟踪功能，并对PHP引擎进行了实现.

上述方法属于消极污点分析，即对不可信输入进行污点标记，并在程序执行过程中对这些污点标记进行传播.但是由于不可信输入的类型和来源均比较广泛[29]，对这些数据的漏标记很容易造成漏报.而相对来说，可信数据的来源一般比较固定，如程序员写在Web程序中的常量字符串[29,31].基于这一思想，研究人员提出了积极污点分析的方法来检测SQL注入攻击：Halfond等人[11,15]提出了WASP，对程序中常量字符串设置可信标记并动态跟踪该可信标记的传播，通过该标记来区分生成的SQL语句中的可信部分和不可信部分.由于所有的不可信输入均以未标记形式存在，该类方法能够避免漏报，较精确地检测SQL注入攻击.

在边界标记方案中，Su和Wassermann在SQLCHECK中[13]用程序随机选的4个字符起始标记和结束标记来对不可信的用户输入进行标识，将SQL语句的上下文无关文法转换为一个支持该起始标记和结束标记的上下文无关文法，若在检查点不能根据新的文法对带有起始和结束标记的SQL字符串进行解析，则说明用户输入影响了SQL的语法结构，从而判定发生了SQL注入攻击.李舟军等人的PHPHard[32]则基于类似的边界标记思想，积极污点标记PHP应用中常量字符串和内联HTML代码，通过边界标记的传播来动态跟踪响应页面的安全区间，用来检测跨站脚本攻击.

在随机化方案中, Boyd和Keromytis认为影响SQL语句语义结构的关键词必须来自于程序员写的常量字符串，而不能来自不安全的用户输入，他们设计的SQLrand[33]是一种类似指令集随机化的防护方案，将常量字符串中的SELECT、WHERE等关键词后附加一个随机整数进行随机化，通过随机化来标记可信的关键词，然后在应用程序和数据库之间设置一个中间代理，该代理基于一个支持随机化关键词的SQL语法解析器来检查SQL语句的合法性并将其去随机化后传输给数据库.攻击者可以猜测作为污点标记的随机整数并尝试构造攻击，此外，由于需要一个代理在应用程序和数据库之间进行通信，SQLrand的部署也受到限制.

7 结 论

本文提出了基于敏感字符的SQL注入攻击防御方法，结果表明该方法能够高效、精确防御SQL注入攻击.该方法首先基于积极污点分析思想，将污点标记范围从可信的常量字符串缩小到可信的SQL敏感字符；其次利用UTF-8单字节字符的编码空洞，采用编码转换的方式对可信敏感字符进行污点标记，避免了额外开辟空间存储污点信息；最后利用污点信息区分可信敏感字符和非可信敏感字符，在非可信敏感字符前添加转义符，防御SQL注入攻击.该方法实现为PHP插件，易于部署，可以自动和精确防御SQL注入攻击，广泛适用于UTF-8编码的Web应用程序.

本文的防护效果实验验证了PHPGate对SQL注入攻击防御的有效性.尽管实验中的攻击案例都是利用已知漏洞来构造攻击输入，但该方法同样可以对利用未知漏洞的SQL注入攻击进行防御，因为无论漏洞成因以及攻击输入如何构造，污点信息均以非标准单字节编码的形式传播到SQL语句，可以通过污点信息区分可信和非可信敏感字符，进而通过对非可信敏感字符的转义来防御针对未知漏洞的SQL注入攻击.

[1]Ray D, Ligatti J. Defining code-injection attacks[C] //Proc of the 39th Annual ACM SIGPLAN-SIGACT Symp on Principles of Programming Languages. New York: ACM, 2012: 179-190

[2]Ray D, Ligatti J. Defining injection attacks[G] //LNCS 8783: Proc of the 17th Int Conf on Information Security. Berlin: Springer, 2014: 425-441

[3]The Open Web Application Security Project. OWASP TOP10 critical Web application security risks[EB/OL].[2015-11-05]. https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project

[4]Zhao Yufei, Xiong Gang, He Longtao, et al. Approach to detecting SQL injection behaviors in network environment[J]. Journal of Communications, 2016, 37(2): 88-97 (in Chinese)(赵宇飞, 熊刚, 贺龙涛, 等. 面向网络环境的SQL注入行为检测方法[J]. 通信学报, 2016, 37(2): 88-97)

[5]The Open Web Application Security Project. SQL Injection Prevention Cheat Sheet[EB/OL].[2015-11-05]. https://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet

[6]Clarke J. SQL Injection Attacks and Defense[M]. Amsterdam: Elsevier, 2012(Clarke J. SQL注入攻击与防御[M]. 施宏斌, 叶愫, 译. 2版. 北京: 清华大学出版社, 2013)

[7]Balzarotti D, Cova M, Felmetsger V, et al. Saner: Composing static and dynamic analysis to validate sanitization in Web applications[C] //Proc of the 2008 IEEE Symp on Security and Privacy. Piscataway, NJ: IEEE, 2008: 387-401

[8]Kieyzun A, Guo P J, Jayaraman K, et al. Automatic creation of SQL injection and cross-site scripting attacks[C] //Proc of the 31st Int Conf on Software Engineering. Piscataway, NJ: IEEE, 2009: 199-209

[9]Martin M, Lam M S. Automatic generation of XSS and SQL injection attacks with goal-directed model checking[C] //Proc of the 17th USENIX Security Symp. Berkeley: USENIX Association, 2008: 31-43

[10]Appelt D, Nguyen C D, Briand L C, et al. Automated testing for SQL injection vulnerabilities: An input mutation approach[C] //Proc of the 2014 Int Symp on Software Testing and Analysis. New York: ACM, 2014: 259-269

[11]Halfond W G J, Orso A, Manolios P. Using positive tainting and syntax-aware evaluation to counter SQL injection attacks[C] //Proc of the 14th ACM SIGSOFT Int Symp on Foundations of Software Engineering. New York: ACM, 2006: 175-185

[12]Son S, Mckinley K S, Shmatikov V. Diglossia: Detecting code injection attacks with precision and efficiency[C] //Proc of the 2013 ACM SIGSAC Conf on Computer and Communications Security. New York: ACM, 2013: 1181-1192

[13]Su Z, Wassermann G. The essence of command injection attacks in Web applications[C] //Proc of the 33rd ACM SIGPLAN-SIGACT Symp on Principles of Programming Languages (POPL). New York: ACM, 2006: 372-382

[14]Offensive Security. Exploits Database[EB/OL].[2015-11-05]. https://www.exploit-db.com

[15]Halfond W G J, Orso A, Manolios P. WASP: Protecting Web applications using positive tainting and syntax-aware evaluation[J]. IEEE Trans on Software Engineering, 2008, 34(1): 65-81

[16]Medeiros I, Neves N F, Correia M. Automatic detection and correction of Web application vulnerabilities using data mining to predict false positives[C] //Proc of the 23rd Int Conf on World Wide Web. New York: ACM, 2014: 63-73

[17]Shar L K, Briand L C, Tan H K, et al. Web application vulnerability prediction using hybrid program analysis and machine learning[J]. IEEE Trans on Dependable and Secure Computing, 2015, 12(6): 688-707

[18]Shar L K, Tan H K, Briand L C. Mining SQL injection and cross site scripting vulnerabilities using hybrid program analysis[C] //Proc of the 2013 Int Conf on Software Engineering. Piscataway, NJ: IEEE, 2013: 642-651

[19]Naderi-Afooshteh A, Nguyen-Tuong A, Bagheri-Marzijarani M, et al. Joza: Hybrid taint inference for defeating Web application SQL injection attacks[C] //Proc of the 45th Annual IEEE/IFIP Int Conf on Dependable Systems and Networks(DSN). Piscataway, NJ: IEEE, 2015: 172-183

[20]Bandhakavi S, Bisht P, Madhusudan P, et al. CANDID: Preventing SQL injection attacks using dynamic candidate evaluations[C] //Proc of the 14th ACM Conf on Computer and Communications Security. New York: ACM, 2007: 12-24

[21]Sekar R. An efficient black-box technique for defeating Web application attacks[C] //Proc of the 16th Annual Network & Distributed System Security Symp. Reston, VA: Internet Society, 2009

[22]Liu A, Yuan Y, Wijesekera D, et al. SQLProb: A proxy-based architecture towards preventing SQL injection attacks[C] //Proc of the 24th Annual ACM Symp on Applied Computing. New York: ACM, 2009: 2054-2061

[23]Jovanovic N, Kruegel C, Kirda E. Pixy: A static analysis tool for detecting Web application vulnerabilities[C] //Proc of 2006 IEEE Symp on Security and Privacy. Piscataway, NJ: IEEE, 2006: 258-263

[24]Livshits V B, Lam M S. Finding security vulnerabilities in Java applications with static analysis[C] //Proc of the 14th Conf on USENIX Security Symp. Berkeley, CA: USENIX Association, 2005: 271-286

[25]Wassermann G, Su Z. Sound and precise analysis of Web applications for injection vulnerabilities[C] //Proc of the 28th ACM SIGPLAN Conf on Programming Language Design and Implementation. New York: ACM, 2007: 32-41

[26]Dahse J, Holz T. Static detection of second-order vulnerabilities in Web applications[C] //Proc of the 23rd USENIX Conf on Security Symp. Berkeley, CA: USENIX Association, 2014: 989-1003

[27]Dahse J, Holz T. Simulation of built-in PHP features for precise static code analysis[C] //Proc of the 2014 Network and Distributed System Security Symp(NDSS). Reston, VA: Internet Society, 2014

[28]Nguyen-Tuong A, Guarnieri S, Greene D, et al. Automatically hardening Web applications using precise tainting[C] //Proc of the 20th IFIP Int Information Security Conf. Berlin: Springer, 2005: 295-307

[29]Pietraszek T, Berghe C V. Defending against injection attacks through context-sensitive string evaluation[G] //LNCS 3858: Proc of the 8th Int Conf on Recent Advances in Intrusion Detection. Berlin: Springer, 2005: 124-145

[30]Xu W, Bhatkar S, Sekar R. Taint-enhanced policy enforcement: A practical approach to defeat a wide range of attacks[C] //Proc of the 15th Conf on USENIX Security Symp. Berkeley, CA: USENIX Association, 2006: 121-136

[31]Mui R, Frankl P. Preventing Web application injections with complementary character coding[G] //LNCS 6879: Proc of the 16th European Symp on Research in Computer Security. Berlin: Springer, 2011: 80-99

[32]Wang Yi, Li Zhoujun, Guo Tao. Literal tainting method for preventing code injection attack in Web application[J]. Journal of Computer Research and Development, 2012, 49(11): 2414-2423 (in Chinese)(王溢, 李舟军, 郭涛. 防御代码注入式攻击的字面值污染方法[J]. 计算机研究与发展, 2012, 49(11): 2414-2423)

[33]Boyd S W, Keromytis A D. SQLrand: Preventing SQL injection attacks[G] //LNCS 3089: Proc of the 2nd Int Conf in Applied Cryptography and Network Security. Berlin: Springer, 2004: 292-302

[34]Mui R. Techniques for injection-safe Web applications[D]. New York: Polytechnic Institute of New York University, 2013

[35]Ahuja B K, Jana A, Swarnkar A, et al. On preventing SQL injection attacks[G] //AISC 395: Advanced Computing and Systems for Security. Berlin: Springer, 2016: 49-64

[36]Heart K. Process Using Universal Sanitization to Prevent Injection Attacks: USA, US20150156209A1[P]. 2015-06-04

[37]Zekan B, Shtern M, Tzerpos V. Protecting Web applications via unicode extension[C] //Proc of the 22nd IEEE Int Conf on Software Analysis, Evolution and Reengineering (SANER). Piscataway, NJ: IEEE, 2015: 419-428

[38]Masri W, Sleiman S. SQLPIL: SQL injection prevention by input labeling[J]. Security and Communication Networks, 2015, 8(15): 2545-2560

Zhang Huilin, born in 1987. PhD candidate in the Institute of Computer Science and Technology, Peking University. Her main research interests include software and Web security.

Ding Yu, born in 1988. PhD. His main research interests include software and system security (dingelish@pku.edu.cn).

Zhang Lihua, born in 1991. Master. Her main research interests include software and system security (zhanglh@pku.edu.cn).

Duan Lei, born in 1989. Master. His main research interests include software and system security (lei_duan@pku.edu.cn).

Zhang Chao, born in 1986. Postdoctor at University of California, Berkeley. His main research interests include software and system security (chaoz@berkeley.edu).

Wei Tao, born in 1975. PhD. Chief Security Scientist of Baidu Inc and the Co-organizer of UC Berkeley BitBlaze Group. His main research interests include mobile security, network and Web security (lenx.wei@gmail.com).

Li Guancheng, born in 1993. Master candidate in Peking University. His main research interests include software and system security (sunatum@outlook.com).

Han Xinhui, born in 1969. PhD. Senior engineer in Peking University. Member of China Computer Federation. His main research interests include network security and Web security.

SQL Injection Prevention Based on Sensitive Characters

Zhang Huilin1, Ding Yu1, Zhang Lihua1, Duan Lei1, Zhang Chao2, Wei Tao3, Li Guancheng1, and Han Xinhui1

1(InstituteofComputerScienceandTechnology,PekingUniversity,Beijing100080)2(UniversityofCaliforniaatBerkeley,Berkeley,CA, 94720)3(BaiduUSALimitedLiabilityCompany,Sunnyvale,CA, 94089)

SQL injection attacks are prevalent Web threats. Researchers have proposed many taint analysis solutions to defeat this type of attacks, but few are efficient and practical to deploy. In this paper, we propose a practical and accurate SQL injection prevention method by tainting trusted sensitive characters into extended UTF-8 encodings. Unlike typical positive taint analysis solutions that taint all characters in hard-coded strings written by the developer, we only taint the trusted sensitive characters in these hard-coded strings. Furthermore, rather than modifying Web application interpreter to track taint information in extra memories, we encode the taint metadata into the bytes of trusted sensitive characters, by utilizing the characteristics of UTF-8 encoding. Lastly, we identify and escape untrusted sensitive characters in SQL statements to prevent SQL injection attacks, without parsing the SQL statements. A prototype called PHPGate is implemented as an extension on the PHP Zend engine. The evaluation results show that PHPGate can protect Web applications from real world SQL injection attacks and introduce a low performance overhead (less than 1.6%).

SQL injection attack; trusted sensitive character; dynamic taint analysis; positive taint analysis; UTF-8 encoding

2016-06-16；

2016-08-11

国家自然科学基金项目(61572149,61402125)

韩心慧(hanxinhui@pku.edu.cn)

TP393.08

This work was supported by the National Natural Science Foundation of China (61572149, 61402125).