万仕贤 赵 瑜 吴承荣

(复旦大学网络信息安全审计与监控教育部工程研究中心 上海 200433)

0 引 言

在传统信息安全漏洞中，漏洞产生的本质原因来自于产品实现的缺陷[1]。通过理论安全证明的产品在具体产品实现的过程中也会因为开发者实现的差异导致不可预计的后果。在2014年，OpenSSL 1.0.1版本爆出漏洞“心脏滴血”(CVE-2014-0160)[2]，攻击者可以通过构造特殊的网络请求包，从服务器内存读取多达64 KB的数据。SSL协议的理论安全性已经获得行业内的普遍认可，但由于开发人员在具体实现时考虑不周全，并不能完全保证产品的安全性，因此在现实中存在漏洞或缺陷是不可避免的。传统的网络空间安全体系中更多的是基于威胁特征感知的精确防御[3]。含有高风险漏洞的软件安全并不是建立在软件自身的内生安全上，软件安全更多地取决于外在的攻击者及内部防守者所掌握的可利用信息。攻击方和防守方处于一种信息不对等的环境中，防守方并不能检测出应用系统中所有的漏洞，只能力求在攻击方攻击完成以后尽可能快地修复受损系统，以减少受攻击而带来的损失。

1 研究现状

国外针对主动防御技术近年来应用研究成果之一称为移动目标防御技术(Moving target denfense,MTD)。MTD技术主要包括在三个方面的动态化，包括网络层、软件应用层和设计架构层[4]。在MTD Workshop[4]中有提到新的MTD防御思想也正在和许多新的技术相融合，例如MTD与深度学习及一些新数学模型的结合；MTD技术与传统通信网络相结合形成的NMTD(Network Moving Target Defense)[5]也为提供通信安全作出了巨大贡献。MTD技术正在不断将其应用从学术界拓展到工业界。

随着基于动态异构冗余体系(Dynamic Het-erogeneous Redundancy,DHR)[6]的发展，关于拟态Web服务器的整体设计[1]最早被提出。拟态Web服务器中包含了保护底层数据库的“数据库防御模块”，该模块带有明显的拟态数据库的防御特征。随后，基于动态异构冗余架构的路由器防御体系被提出[7]，以及关于拟态数据库[8]的具体设计方法被提出，同时针对数据库的同步及表决器表决方法的设计也有多项经典方法被提出。

针对数据库拟态化应用的需要，文献[8]给出了基于异构冗余的拟态数据库的总体设计并针对性地给出了防御性能测试，利用异构处理方法，将同构的SQL操作语句分别异构化处理并加以裁决，有效地防御了许多系统设计不足所带来的潜在攻击，使整个数据库系统具有内生的安全性，在设计上完整还原了拟态防御体系原理。

文献[9]提出了一种基于大数表决的数据库离线表决与同步的实现方案DBOLVS。相较于传统数据库同步问题，拟态数据库的子数据库之间是相互对等的关系，同步方法需要依据“少数服从多数”的原则，根据所有的子数据库状态来同步整体拟态数据库的状态。该方法完善了拟态数据库服务的离线数据库表决和同步服务，同时针对一些特定的数据库可以有效屏蔽恶意操作对数据库产生的影响。

文献[10]在经典的基于编辑距离的字符串相似度计算法计算方法之上，提出了一种应用于拟态Web服务器的基于编辑距离和最长公共子串的相似度求解方法。该方法引入了最长公共子串长度，根据网页字符串的特点和恶意的网页篡改行为重新定义新的相似度计算公式;利用改进的双向跨越比较方法求解最长公共子串。这两种改进策略优化了传统字符串比较方法的时间复杂度，针对拟态Web服务器异构多变的特性，使得计算相似度结果也更加准确，降低了系统对于正常返回信息的误判率。但该方法未考虑拟态防御过程中防御系统为了整体拟态化的需要可能会修改网页字符串并导致相似度计算结果出现差异的问题。

文献[11]基于文献[10]的相似度计算方法，提出了一种改进的适用于拟态服务器响应判决的相似度计算方法，针对利用拟态服务器进行有效拟态防御时在一定程度上也会影响响应输出的问题，提出了一种利用网页DOM响应树的判决方法。该方法通过读取网页的动态DOM结构信息，递归处理每个DOM树节点的字符串计算编辑距离，根据设置的响应阈值K2、K3来对响应信息的合法性进行裁决，最终得出合法的响应输出。该方法在响应速度和判决精准度方面相对于传统基于字符的判决方法都有了显著的提升。

2 拟态数据库

2.1 拟态数据库模型设计

由文献[8]可知，拟态数据库在设计上由三个主要模块组成，分别为保留字拟态化模块、指纹过滤模块和拟态中间件模块，如图1所示。

图1 拟态数据库设计

2.2 拟态数据库模块分析

拟态数据库设计架构在整体上主要分为两个部分，一是针对SQL操作指令进行预处理的保留字拟态化模块和指纹过滤模块；二是用于对输出信息进行裁决的表决器模块。

2.2.1保留字拟态化模块和去指纹化模块

在该模块中，针对传统的数据库入侵方法，对执行指令进行指纹化预处理，在指令还未执行前，提前过滤掉带有攻击意图的指令，系统结构如图2[8]所示。

图2 指令预处理

由图2可知，对SQL保留字进行指纹拟态化处理，再通过对带有指纹特征的保留字进行表决，可以在一定程度上抵御传统的SQL注入攻击。当攻击者未获得拟态化模块指纹特征时，从客户端向目标系统发送传统恶意注入攻击，在经过拟态指纹特征处理以后，该攻击语句不带有系统规定的指纹特征，被表决器否决。拟态防御的攻击任务成功概率计算公式[6]为：

(1)

式中：qvuli为攻击者利用vuli异构体漏洞完成攻击的成功率。在异构环境足够复杂的情况下，攻击者要掌握足够多的指纹特征来完成攻击的难度是足够困难的。受不同的异构体的影响，越是对环境依赖度高的攻击越容易被拟态防御系统所防御[9]。攻击者精心构造符合采集信息特征的SQL攻击语句，该语句通过特征处理后加上特征指纹，但其特征与对应的执行体的指纹特征不相符，因此该执行语句仍会被表决器否决，不会向下层执行模块传递。

2.2.2表决器模块

表决器模块在系统中用于裁决SQL执行语句和最终的返回数据，其表决效果将影响SQL数据库的安全和网站的数据安全。系统接受来自n个执行体的异构语句，通过集中表决的形式，依照“少数服从多数”的原则，从多个处理结果中得到归一化的输出结果，并将结果交付给数据库执行，数据库将执行结果返回给表决器，表决器将多数据库应用的返回结果归一化表决，最后将表决结果发送给客户端进行展示。

3 攻击实验思路设计

DHR理论体系是防御评估系统设计的基础，在设计上充分利用了动态性、随机性、多样性等防御机制，基于“相对正确”公理，采用异构冗余架构来搭建在不可信环境下对未知攻击的防御。其安全性可由不同层次的安全产品和安全应用相互之间的异构来保证。由此本文分析得出DHR系统架构的安全目的是在每个单独的执行体自身有漏洞或后门，甚至存在一定的“共谋漏洞”的情况下，实现针对“未知漏洞”和“未知攻击”的防御，甚至这些“未知攻击”的方法和原理对于防御者也是未知的。同理，具体到拟态数据库中，假定在实际应用中“指纹过滤模块”也并不能识别和过滤所有的攻击，无论是对防御者已知的攻击或者未知的攻击，仍存在无法完全可知的操作可以到达数据库服务，并对数据库服务产生不可估计的影响。所以在这个假定的基础上，本文将主要讨论底层数据库服务集群和后向的输出部分，重点分析削弱其安全性的可能性。

本文分析得出任何从理论上论证安全的机制并不能完全避免具体实现上的漏洞和缺陷，DHR架构的输入代理、裁决、调度等功能的实现也是基于具体的产品和应用实现，这些具体应用的漏洞威胁将会被放大至针对整个DHR系统的威胁，依然存在会被攻击者攻破系统的可能。

假设在理论设计方面，DHR系统自身在现理论上是不存在可以利用的漏洞，在此基础上寻找反制DHR框架可能存在的方法。DHR的核心思路是异构冗余从“相对正确”公理出发，其前提假设如下[6]：(1)功能F存在n个功能等价的处理空间，且处理空间之间是异构的；(2)问题W存在n个解决算法，且算法间不相同，但解算结果应当是一致的；(3)每个处理空间都包含一种算法且得到正确结果是大概率事件；(4)所有算法都有完全相同的输入激励；(5)对各空间算法的输出向量要做择多判断，并以多数相同的输出结果作为正常状态的判据。

在理论条件下这些假设有效地保证了DHR系统的安全性；而在具体应用环境中，由于系统安全是由具体的安全设计和服务来保证的，针对具体应用服务的针对性的渗透攻击将有效地削弱理论假设的强度，从而降低DHR系统的现实安全性。

3.1 指令拟态化处理分析

本文由拟态数据库理论设计分析得知，指纹拟态化模块主要完成的功能是对数据库中预存的保留字添加动态字符指纹。当接收到用户发来的请求时，由于攻击者无法提前预知并构造随机指纹，并且多个异构冗余体的字符串指纹在满足不相同的情况下，无法由一条命令同时满足多个异构体的指纹判定，所以攻击者的恶意指令在到达异构体时不会带有与异构体相匹配的指纹序列，将会被前向表决器否决，其效果不会被后向的数据库所执行。

以上是异构指纹模块设计所要达到的理论预期，本文根据实际情况给出两点针对性的分析：(1)关键字本质上是一串被数据库赋予特定含义的字符，虽然根据拟态数据库安全需要被加上了动态变化的指纹信息来加以保护，但由于数据库解释器的多样性，由原生关键字字符经过多种变化组合之后的字符串仍然可以被解释器有效识别。例如使用大小写混写的方式字符“SElecT”在大多数的数据库应用中被等效识别为“select”关键字;在PHP和MySQL的Web组合应用中，传递字符“/*!%53eLEct*/”也是等效于“select”关键字。同样地，在数据库应用中有可以达到相同功能的等效替换关键字，例如“like”和“rlike”在模糊查找中就可以完成同样的功能。这些复杂的情况都将增加指纹异构的复杂程度，所以必须要对关键字的异构指纹进行处理而非穷尽所有可被数据库解释识别的字符串组合。这些变化的字符串在经过异构指纹模块时并不会被当作关键字进行指纹判定和处理，但当数据库被执行时却可能产生危害效果。(2)对关键字的异构指纹处理会限制影响正常用户的正常输入和存储。因为数据库中大多数关键字是与人类语言语义相吻合的，所以大量的指纹关键字异构处理必然会导致用户的正常日常行为被限制。例如用户的输入中将不能带有“where”“from”这类日常生活普遍使用的字符，这将给用户的系统体验带来极大的不便，影响业务正常逻辑。

综上所述，本文指出指纹过滤模块并不能过滤所有的潜在攻击，仍存在有特性构造可以绕过指纹过滤模块到达数据库应用并被执行。经过理论分析，前向的指纹异构模块对经过多样性变化的字符串安全性已被有效降低，随后的设计将基于此分析重点假定某个攻击的payload通过了指纹过滤模块并进入数据库，那么由多个异构的数据库构成的DHR系统能否显著提高防御能力的问题。

3.2 数据库语法的差异性

SQL数据库都是基于SQL理论体系设计的，大部分的数据库系统遵循一套相同的操作语言体系。例如在数据库应用中查询语句大都是采用以下模式进行查询操作：

“SELECT column_name,column_name

FROM

table_name

[WHERE Clause]

[LIMIT N][ OFFSET M]”

而更新操作又以以下模式完成对数据的更新：

“UPDATE table_name

SET field1=new-value1,field2=new-value2

[WHERE Clause]”

在符号SQL语句逻辑框架的基础上，每个数据库服务又根据自己的解释器特性相应地具有自己语言体系的特点，针对相同的字符符号或者函数调用，在不同的数据库应用服务中可能会出现截然不同的反馈。本文发现这种数据库服务之间的区别性处理虽然不是一种漏洞服务，但却可以被攻击者利用，从正常的服务逻辑来完成非预期攻击。例如在MySQL数据库中对字母大小写是非敏感识别的，字符a与字符A被识别相等，但在PostgreSQL数据库中字符a和字符A被判定为不同。利用不同数据库之间语法的特异性可以改造针对表决器输出的攻击向量。如下列举出一些不同数据库间可供攻击使用的差异处理：

(1)“#”和“--”(末尾有空格)在MySQL中被当作注释符号处理，在PostgreSQL和SQLite3中使用“--”作为注释符号。

(2)在MySQL和SQLite3中大小写符号非敏感处理，在PostgreSQL中对大小写敏感。

(3)在MySQL中可以使用database.table或者table的方法来表示所选择的数据表，在SQLite3和PostgreSQL中仅能通过table的方式来表示数据表。

(4)某些函数调用不能在不同数据库间执行，例如“ifnull”方法支持MySQL数据库和SQLite3数据库，但不支持PostgreSQL数据库。

因此，本文发现可以利用这种不同数据库间的处理的差异性，使用不同数据库之间的错误处理的区别性来构造输出内容的相同性，以此来绕过表决器的相似性表决。

3.3 共有漏洞以及共谋攻击

根据对DHR系统的详细分析，本文发现当貌似完全异构的执行体，实际上具有相同的漏洞，而在某些外界因素的作用下，使得具有相同漏洞的异构执行体被部署到DHR框架中。这种情况下，针对该漏洞的攻击将形成多个执行体被同时攻破，可能形成相同的输出。DHR的防御效果取决于相同漏洞/相似漏洞存在的概率，以及关于该漏洞的l阶输出一致性[6]。

类比到在现实软件设计中，不同开发团队所设计的异构系统具有软件共有故障或者软件共有漏洞的概率是极低的。由于应用服务体的异构化，导致软件应用服务多种多样，虽然可能存在理论上一致的漏洞，例如存在缓冲区溢出、内存泄露等问题，但在不同的软件应用中对应的内存地址是不相同的，会使得同一攻击并不能在多个异构体中发挥作用。

对于通常意义上的软件，不同的开发团队若同时开发实现某个等价功能的异构体，事先若不进行“同谋”，形成相同漏洞的可能性极低。而当前普遍采用的3层结构开发的业务程序不同，不同开发团队即使在不共谋的情况下，也很容易达到“相同漏洞”或“相似漏洞”的效果。(1)中间件大都采用字符脚本方式，脚本相比二进制程序对攻击具有更大的“宽容”特性，发起攻击并不一定需要精确知晓某个内存地址。不同执行在运行时的内部微观差异性对攻击成功概率的影响不敏感。(2)普遍采用的Web-应用-数据库的三层结构编程模式，使得最后生成数据库查询的语句通常由应用服务器程序中的固定部分和由页面输入的动态部分拼接而成并解释执行，这种方式必然会存在脚本语句在解释环节的内容字段和操作原语字段的混淆，产生漏洞的本质原因是相通的。(3)基本上所有的数据库都遵循SQL语句标准和应用习惯，所以异构的数据库的保留字高度重合(如“select”“where”)。数据查询语句是跨数据库通用的(如果数据库表设计一致的话)，所以无论如何触发漏洞，只要达到某条语句被执行的目的，这个语句在不同数据库上执行的结果理应相同，因此天生就具备漏洞被利用后输出相同结果的“潜力”。(4)基本上所有数据库均有定义分隔符、注释符、转义符，并且不同数据库中对这些符号的定义高度相似，如“‘”被大多数数据库作为分隔符，而“#”被大多数数据库作为注释符，而分隔符、注释符在诸如SQL注入攻击中具有至关重要的意义，这将导致存在通用的漏洞触发方法的可能。同时针对字符大小写的敏感性问题也将成为诱发攻击的一个潜在威胁，有很大可能导致针对某个数据库奏效的攻击串，对另外一个数据库也能奏效。即使没有“共谋”，依然可能具备较高概率的“漏洞输出一致性”。

3.4 输入触发漏洞并控制输出

本文假定针对输出表决器，攻击者执行以获取“敏感数据信息”为目的的攻击。在原本的防御系统设计中，通过注入攻击向量，不同异构体执行向量以后将会导致异常输出，由此被多模表决机制所否决，不会被输出。在正常逻辑应用中，异构执行体在执行相同输入激励的情况下，返回输出也会有细微差异，但由于表决器大多代用语义判定的方法，在可预见的差异范围内返回结果的可变范围是可控的。但这同时也可以为攻击注入提供可能，多模表决机制下，输出内容的判定是相对的，基于“相对正确”公理，“多数输出”被看作相对正确的输出由此否决“少数输出”，在控制恶意输出的数量达到压制正确输出的情况下，就可以让恶意输出从多模表决机制下实现逃逸。

基于上述理论分析，本文构造“同一输入触发多个漏洞”假设，考虑以下场景：

(1)假定由3个异构等价数据库执行体构成异构防御系统，且相互独立地执行数据库请求指令，并将执行结果统一返回给输出表决器，输出表决器采用多模表决原则进行表决。

(2)等价执行体实现的是一个基于Web的数据库查询操作，输出的是一个HTTP请求“http://example.dhr.com/input/xxx.jsp?var=query_parameter”，其中var是用户的待查询参数，这个参数将用于生成具体的数据库查询指令。

(3)3个等价执行体中分别维护3个不同的数据库应用服务，每个数据库服务都至少与其他2个数据库服务存在一个产品实现上的差异或者漏洞。分别将3个数据库服务可被利用的缺陷命名为vul1、vul2、vul3。

(4)攻击者精心构造一个Web请求，该Web请求将作为3个异构等价执行体中数据库服务的执行指令。

(5)数据库应用1中的vul1和数据库应用2中的vul2被同时触发，生成返回信息;等价执行体3中由于执行错误，生成消息为空。

(6)假设攻击者精心设计的攻击代码可以精确控制输出，使得数据库应用1和数据库应用2形成相同的输出，例如提前存储的用户信息或者管理员信息。

(7)多模裁决机制采用择多判决的原则，正常的执行体由于输出表决处于少数派，将被清洗，被攻击执行体的恶意输出占据多数派，将被输出。

以上例子仅针对HTTP请求中的URL请求参数进行构造针对数据库应用服务的攻击。在完成“同一输入触发多个漏洞”的情况下，即使多个异构体之间独立完成请求操作仍不能降低“1阶输出一致性”的概率。被攻击的异构执行体在输出表决中占优势地位，将导致正确的异构体被清洗，针对新被换入的等价执行体，将重复旧执行体的操作，最后达到完全恶意化输出表决的目的。

4 评估场景设定

从拟态数据库的理论设计方案中分析得出，表决器的表决结果将会直接影响底层数据库的执行和客户端返回结果。前向表决器的输入数据来自各执行体异构处理的返回语句，其异构处理的方式由拟态化模块和指纹化模块决定；后向表决器用于对服务器返回数据结果进行判定，其输入数据来自于底层各提供服务器的数据库的指令执行结果，输入数据的内容直接决定于底层各类型的数据库。据分析当前应用环境下，SQL数据库种类繁多，不同的数据库采用不同的数据结构来组织和搭建自己的存储体系，其执行指令均以SQL理论为依据，但不同的数据库产品的执行语句之间还是存在差异，相同的语句在不同的数据库产品之间会执行不同的操作。

前向的异构指纹模块的测试工作在文献[7]中已经给出比较详细的分析，且在上文的反制分析部分已经从理论上分析得出降低异构指纹模块安全性的思路，可为后向的表决器攻击提供绕过基础，所以本文重点将防御评估对象放在后向输出部分，并在语义分析相似度判决的基础上使用条件更为苛刻的完全内容比较方式，异构执行体间的输出将完全按照内容比对的方向进行输出裁决，依据“黑盒测试”原理，若统一将表决器看作程序黑盒，输入固定的情况下在经过表决器裁决以后一定且仅能有唯一恒定输出。据此为了简化评估模型，作如下规定:

(1)统一将表决器看作程序黑盒，表决器的表决算法和相似度求解方法不会动态影响表决结果。

(2)表决器输出结果影响因素唯一取决于输入数据。

(3)评估实验仅针对数据库查询操作进行评估，攻击向量不涉及修改数据库数据，即不触发拟态数据库的同步机制[13]。

(4)在基于归一化表决的原则下，所有数据库都执行相同的操作执行。

(5)为了简化实验操作，在给出降低安全性操作的理论分析上，此时的评估实验暂时不考虑指纹异构模块的安全防御效果。

4.1 防御系统抽象设计

针对评估重心和拟态数据库的设计方案，设计如图3所示的评估系统用于安全系统评估。

图3 防御评估系统设计

该评估系统主要模块功能如下：

(1)消息转发模块。消息转发模块作为整个系统的起点，首先会接收来自客户端的HTTP请求，将用户的请求信息抽离并重新整理以后分别复制发往不同的应用数据库。

(2)底层数据库群模块。根据拟态化设计要求，选择不同的应用数据库为用户请求提供服务，底层数据库群使用同一执行指令完成操作并将各操作结果独立地返回给表决器以供裁决。

(3)表决器模块。表决器模块接收数据库应用的返回结果，通过归一化数据以后，裁决出唯一表决结果，并将结果返回给客户端展示。

4.2 服务应用选择

服务应用如表1所示。

表1 应用服务选择

4.3 系统流程分析

前端服务器提供一个待查询页面，页面中为用户提供一个待查信息交互框，用户将请求填写在交互框之后，通过交互最终会将操作结果返回该页面。用户请求从客户端Chrome浏览器发出，转发代理件在接收到用户请求以后对请求做安全性分析过滤掉危险操作，然后将通过安全性判定的请求分别复制转发底层的应用数据库。三组不同的应用数据库MySQL、PostgreSQL、SQLite3在接收到操作请求以后，会分别执行指令操作然后将执行结果返回给表决器。表决器通过黑盒处理，判决出最终返回结果并将结果返回给用户浏览器显示。整个程序设计的伪码算法如下：

输入：客户端请求参数nativeRequest。

begin

if get client requests

//对用户请求进行安全性检查和处理返回processedRequests

processedRequests=check_input(nativeRequest);

//分别将处理完的请求processedRequests转发给数据库应用

//容器container1、container2、container3

//数据库应用操作返回信息为response

response1=send_to_container1(processedRequests);

response2=send_to_container2(processedRequests);

response3=send_to_container3(processedRequests);

//使用表决器对不同数据库应用返回的信息进行裁决

//生成最终的client端返回信息

clientText=judge(response1,response2,response3);

//将信息发送client端

send_to_client(clientText);

send

end if

end

5 实 验

5.1 预存储数据

三组数据库中的数据库信息及数据库中的表信息、列信息均保持一致，用户正常信息存储在student表中，而敏感信息存储在admin_test表中，判定注入成功的标志是输出admin_test表中的敏感信息。表2为admin_test表和student表中预存储的信息。

表2 预存储数据

5.2 攻击实验设计

SQL注入漏洞均是从与后端数据库进行交互的地方触发，针对后端异构的数据库群，分别搭建三组和待测防御系统相同的数据库应用，先构造针对单一数据库的攻击向量，然后在三组数据库的单一攻击向量的基础上再修改出可针对三组数据库的共性攻击向量，以达成可通过表决器输出的目的。

(1)在单独实验系统中，先后使用SQLMAP、POSTMAN等注入工具分别向MySQL、PostgreSQL、SQLite3三组数据库应用进行注入攻击，寻找可供使用的针对三种不同数据库的攻击向量。

(2)在防御系统中，分别使用上述确定的攻击向量向防御系统发出请求，观察不同数据库的响应，观测表决器输出。

(3)在防御系统中，使用组合攻击向量向防御系统发出请求，以寻找不同数据库之间共有的漏洞为切入点，尝试通过以相同的攻击漏洞来引发不同数据库的同内容输出，最后绕过表决器的内容表决，将敏感信息输出到客户端网页。

5.3 评估流程

1)在单独实验环境中，针对三种防御较弱的数据库应用，基于联合查询的漏洞及不同数据库对特殊字符处理的漏洞，可较为容易地构造出针对三种不同数据库的攻击向量，将三组攻击向量分别命名为攻击向量A、攻击向量B、攻击向量C，并成功输出admin_test表中的敏感信息。

例如针对SQLite3数据库使用的攻击向量A定义如下:“jeack′%0AunionunUNIONion%0AsELECT%0Asel

SELECTect%0A*%0AfrOFROMm%0Aadmin_test;#”；针对MySQL数据库使用的攻击向量B定义如下：“jeack′

%0AunionunUNIONion%0AsELECT%0AselSELECTect%0A*%0AfrOFROMm%0Atest1.admin_test;%23”；针对PostgreSQL数据库使用的攻击向量C定义如下：“jeack′%0AunioNunUNIONion%0AsELECT%0AselSELECTect%0A*%0AfrOFROMm%0Aadmin_test;--”。

攻击向量A、B、C基于相同原理构造，以向量A为例解释构造原理。根据对数据库进行模糊测试和信息侦测的结果可知，用户数据请求输入部分存在联结注入漏洞，原执行语句为大体上满足“select[column] from [table] where [condition]”的模式，利用“union”和“select”关键字构造联结查询攻击，攻击模式大体上满足“select [column] from [table] where [condition] union select [attack]”模式。针对可能存在漏洞系统，使用WAF(Web Application Firewall)过滤数据库“select”和“union”等关键字，并过滤空格符号，所有带有空格的语句会被连接成一句无空格的字符串。为了避免可能存在的联结注入，同时还针对性地过滤“select union”字符串。针对如上采集的信息，首先利用“双写绕过”方法，绕过关键字过滤;利用换行符‘ ’等效替换空格，等效为一种空格符以达到分割语句的效果，“%0A”经过URL编码之后会转码为‘ ’;利用多写原理和大小写混合的方式，在绕过关键字过滤的基础上可以继续绕过关键字符串过滤;最后针对SQLite3的注释规则，使用“#”最后注释符，截断原操作指令的末尾语句，保证攻击指令可以正常执行，值得一提的是在MySQL数据库中采用“#”(“%23”经过URL编码以后是“#”)及PostgreSQL数据库采用“--”作为注释符。图4给出了注入暴露SQLite3数据库的结果，MySQL数据库注入和PostgreSQL数据库注入可以达到相同结果。

图4 注入效果1

图4所示的部分即为管理员敏感信息，构造针对单数据库系统的攻击向量可以成功暴露出SQLite3数据库中的管理员敏感信息。

2)正常用户逻辑下，用户提供一个待查询字符串“luna”，用于查询用户“luna”的信息，该查询字符串中没有包含恶意代码，三组数据库服务均正确查询后将查询结果统一返回到表决器表决，表决器根据“少数服从多数”的原则，对查询内容进行完全字符比对表决。图5给出了正常查询逻辑的结果。

图5 正常查询结果

3)分别以攻击向量A、B、C为基础构造攻击向量，将针对三种不同数据库特性的攻击ABC重组合为具有兼容攻击性的攻击向量。向防御系统发送请求，三组结果中相对应的数据库下均能爆出敏感信息，但在其他两组数据库同时执行攻击指令时引发错误异常，返回结果均为空，在经过表决器裁决以后最终返回结果也为空，此时有效防御了常规攻击。例如使用针对MySQL数据库重新定义针对防御系统进行攻击的攻击向量D。攻击向量D定义如下:“jeack′%0Aunion

unUNIONion%0AsELECT%0AselSELECTect%0A*%0AfrOFROMm%0Aadmin_test%0AunioNunUNIONion%0AsELECT%0AselSELECTect%0A*%0AfrOFROMm%0Atest1.admin_test;%23”。图6给出了构成攻击被成功防御的结果。

图6 防御效果

4)在过程1)和过程3)的基础上分别从针对不同数据库的漏洞共性，构造符合多组数据库漏洞特性的攻击向量。根据数据库应用间内生定义的函数名的差异，以及定义使用表名和语法上的差异构造攻击向量E。攻击向量E定义如下:“ja1ck%27%0AUNIUNIONON%0AALL%0ASELSELECTECT%0AIFNULL(CAST(username%0AAS%0ACHAR),0x20),IFNULL(CAST(passwd%0AAS%0ACHAR),0x20)%0AFFROMROM%0Aadmin_test;--+”。

攻击向量E中仍采用“双写绕过”的方法来攻击WAF中的关键字过滤;利用不引人注意的关键字“all”和“select”配合，绕过字符串“union select”过滤，降低被系统识别的风险，增加注入成功的可能性;使用“%0A”来针对空格过滤;使用“ifnull”方法来执行结果进行判定，判定其返回字符串是否为NULL，该方法在PostgreSQL数据库中无效，但在另外两个数据库中有效，数据库表名的选择使用table的方式，避免使用database.table的方式，可以有效兼容三种数据库语法;末尾使用“--+”作为截断注释符，“+”会被转义为“”(空格)，兼容三种数据库的注释语法。图7给出了成功绕过表决器输出的结果。

图7 注入效果2

将攻击向量E作为攻击请求输入到防御系统，结果显示MySQL数据库和SQLite3数据库如预期执行输出敏感信息，PostgreSQL数据库执行异常返回为空，通过表决器裁决以后将敏感信息输出到客户端，达成攻击诉求。

6 评估结果和分析

在整个攻击流程中，将攻击行为和攻击结果整理见表3。

表3 攻击结果总结

在攻击者掌握较少系统应用信息的情况下，构造的单一攻击向量和简单组合的攻击向量可以被表决器有效否决，其安全性也符合异构拟态应用的设计预期;在经过长时间的应用系统信息收集或者基于共谋的系统信息泄露之后，通过组合利用本身异构应用系统的应用安全缺陷，例如，寻找共性处理环节，使得恶意代码(有可能是不同恶意代码)在不同异构体中执行，但输出仍保持一致，实现绕过表决器输出敏感信息的目的。

具体应用的缺陷设计也会在一定程度上放大动态异构冗余系统的被攻击性，在一定程度上降低动态异构冗余系统的理论安全性。同时在了解攻击手段以后也可以针对性地采用如下措施来增强系统的安全性：(1)在拟态数据库结构中，可以通过在指纹过滤环节对来自页面的输入串进行严格检查，过滤掉恶意代码，以提高安全性。(2)在裁决器进一步进行严格的检查，采取更为复杂的策略(例如一票否决并清洗等)，以杜绝此类攻击的发生。(3)在设计异构数据库时，采用不同数据库产品并不能带来足够的“异构性”，真正有意义的异构是数据库表的设计，采用不同的表名、字段名将对攻击起到良好的抵御效果，当然这也将进一步增加数据库同步的复杂性。

7 结 语

本文基于动态异构冗余的Web数据库设计，针对异构数据库中最关键的表决器部分进行安全评估实验，从不利用软件漏洞的基础出发，利用多种数据库服务之间的SQL语言设计特性，完成将系统设计预期之外的数据暴露。论证得出拟态数据库在分析假定保留字指纹异构模块不能完全过滤攻击请求的基础上，异构体在某些环节的处理方法上存在共性，那么系统安全性将会被从应用实现软件层次上被削弱，将会导致系统设计预期之外的信息被暴露，系统设计的理论安全性降低，同时后端的异构数据库的实现对安全性的提升效果有限。DHR架构安全将受实现应用的安全影响，在拟态数据库应用中不同的数据库应用服务将会在应用层服务上降低系统设计的理论安全性，异构体中间层的应用服务选择对整个异构系统的安全性也有着不容忽视的重要作用。

本文在防御模型设计时重点针对输出表决器部分进行了实验和评估，未对数据操作指令进行指纹异构处理，如果在数据请求入库前进行指纹异构化处理，将提升拟态数据库的防御能力，也将同时增加注入的难度。未来工作将在此评估结果的基础上，继续完善设计防御模型，针对增加指纹异构化处理模块和传统防注入方法的模型进行评估和实验，进一步完善拟态数据库的防御设计架构。