浅谈数据库防火墙技术及应用

数据库防火墙仿佛是近几年来出现的一款新的安全设备，但事实上历史已经很长。2010年，Oracle公司在收购了Secerno公司，在2011年2月份正式发布了其数据库防火墙产品（database firewall)，已经在市场上出现很多年头了。

由于数据库防火墙这个词通俗易懂，和防火墙、Web防火墙、下一代防火墙等主流安全产品一脉相承，很多公司也就把自己的数据（库）安全产品命名为数据库防火墙。每家公司对于数据库防火墙的定义各不相同，侧重点也不一样。也就是说，虽然大家都在说数据库防火墙，很有可能是两个完全不同的数据（库）安全设备。 

数据库防火墙顾名思义是一款数据（库）安全设备，从防火墙这个词可以看出，其主要作用是做来自于外部的危险隔离。换句话说，数据库防火墙应该在入侵在到达数据库之前将其阻断，至少需要在入侵过程中将其阻断。 

至于如何定义外部威胁，则需要对于数据库边界进行明确的界定，而这个数据库边界的界定则具有多变性。第一种定义，从极限的角度来看，由于现在网络边界的模糊，可以把所有来自于数据库之外的访问都定义为外部。如果是这个定义来看，防火墙承载的任务非常繁重，可能不是一个安全设备所能够承担的。第二种定义是数据中心和运维网络可以被定义为内部访问，其他访问定义为外部访问，让防火墙不需要去承载内部运维安全和员工安全，从而更好的工作。 

综合看来，我们采用第二种定义，数据库防火墙主要承载数据中心和运维网络之外的数据（库）安全工作。 

一旦准确的定义了什么是外部之后，什么是数据库防火墙就比较清楚了。运维网络之外的访问我们都可以定义为业务访问。

数据库防火墙是一款抵御并消除由于应用程序业务逻辑漏洞或者缺陷所导致的数据（库）安全问题的安全设备或者产品。数据库防火墙一般情况下部署在应用程序服务器和数据库服务器之间，采用数据库协议解析的方式完成。但这并不是唯一的实现方式，你可以部署在数据库外部，可以不采用协议解析。从这个定义可以看出，数据库防火墙其本质目标是给业务应用程序打补丁，避免由于应用程序业务逻辑漏洞或者缺陷影响数据（库）安全。 

常见的应用程序业务逻辑漏洞和缺陷：

SQL注入攻击

cc攻击

非预期的大量数据返回

敏感数据未脱敏

频繁的同类操作

超级敏感操作控制

身份盗用和撞库攻击

验证绕行和会话劫持

业务逻辑混乱

1、SQL注入攻击

SQL注入攻击是数据库防火墙的核心应用场景，甚至可以说数据库防火墙就是为了防御SQL注入攻击而存在的。SQL注入攻击是很古老的攻击手段，特别是互联网普及之后，一直是主流的安全攻击手段。需要特别注意的是，SQL注入攻击的发生不是由于数据库的漏洞导致，而是因为应用程序漏洞和缺陷导致，但是受到伤害和影响的则是数据库。我们的业务应用程序是水平参差不齐的公司和工程师撰写，其代码质量会远远比不上Oracle，微软等大牌公司的产品，SQL注入以及其他可能的漏洞和缺陷存在是必然的事件。甚至可以认为，只要复杂度超越一定程度的任何业务应用程序都会存在SQL注入漏洞。

SQL注入攻击之所以难以防御，其主要原因是其攻击是通过业务应用程序发起的，传统上部署的所有安全措施对于SQL注入攻击基本无效，使其可以简单到达企业最为核心的数据库内部。 

2、cc攻击

即使一个没有任何缺陷的应用程序也可以简单的发起cc攻击。每个应用程序都会存在资源消耗特别高的某些操作，入侵者只要同时调度这些高资源消耗的操作，就会导致数据库服务器失去响应。   

3、非预期的大量数据返回

由于应用程序缺陷，在某些操作中返回了计划之外的大量数据。大量数据返回很容易引起安全性问题。 

4、敏感数据未脱敏

由于历史原因，现有应用程序很少对于敏感数据进行脱敏显示。为了遵循新的安全法规和规则，为了更好的保护客户和公司，在很多情况下我们需要对于应用程序返回数据进行脱敏。 

5、频繁的同类操作

通过应用程序不断的频繁获取敏感信息资料是敏感信息泄露的主要通道之一，数据库防火墙可以通过延迟，通知等响应方式来降低此类数据泄露风险。 

6、超级敏感操作控制

很多应用程序往往存在着权限控制漏洞，无法控制某些敏感操作。比如统方，比如绝密资料的获取等等。

7、身份盗用和撞库攻击

撞库攻击是互联网最大的安全风险之一，绝大部分撞库攻击都是为了身份盗用。

8、验证绕行和会话劫持

由于应用程序缺陷导致起验证安全机制没有生效，比如验证码等，或者会话被劫持导致业务应用程序被非法控制。

9、业务逻辑混乱

由于应用程序漏洞导致业务逻辑混乱，比如在审批中不检查前置流程的存在性和合规性，直接触发下一个流程。

大家可以观察到，很多数据库防火墙都具有数据库漏洞检测和虚拟布丁等功能，甚至于把数据库漏洞检测防御变成了数据库防火墙的核心功能。这个是对于数据库防火墙理解的典型误区，数据库防火墙的核心是检测和防御业务应用程序漏洞而不是数据库漏洞。

当然数据库防火墙部署数据库漏洞检测也有其逻辑基础：当入侵者通过业务应用程序漏洞入侵数据库，特别是SQL注入攻击的时候，入侵者为了获取更大的入侵收益，往往会利用数据库漏洞进行进一步攻击。从紧密流程环节来看，在很多场合下，数据库漏洞攻击可以被看作SQL注入攻击的一个环节，一个成果扩大环节。 

很多人可能会问，Web防火墙也能够防御SQL注入攻击，我为什么还要部署数据库防火墙？首先我们来看看WAF能做些什么：

SQL注入攻击

XSS攻击

CSRF攻击

SSRF攻击

Webshell后门

弱口令

反序列化攻击

命令／代码执行

命令／代码注入

本地／远程文件包含攻击

文件上传攻击

敏感信息泄露

XML实体注入

XPATH注入

LDAP注入

其他

从这个列表看，显然Web防火墙和数据库防火墙所承载的目标区别比较大，SQL注入攻击攻只是两种不同防火墙的为数不多的交叉点。 

数据库防火墙是SQL注入防御的终极解决方案

数据库防火墙和Web防火墙部署位置的不同，决定了两种不同产品对于SQL注入攻击的防御策略和效果会大不相同。

部署位置：Web防火墙作用在浏览器和应用程序之间，数据库防火墙作用在应用服务器和数据库服务器之间。

作用协议：Web防火墙作用在Http协议上，数据库防火墙一般作用在数据库协议上，比如Oracle SQL*Net，MSSQL TDS等。

Web防火墙作用在浏览器和应用程序之间，使他只能够看得见用户提交的相关信息，而用户提交信息往往只是数据库SQL语句的一个碎片，缺乏对于数据库SQL的全局认知，更加不用说SQL语句的上下文关系了。Web防火墙只能做一些基于常规异常特征以及出现过的特征进行识别和过滤，使Web防火墙的SQL注入攻击防御效果依赖于攻击者的水平和创意，只要攻击者具有一定的创意，Web防火墙很难防御SQL注入攻击。

数据库防火墙作用在应用服务器和数据库服务器之间，看到的是经过了复杂的业务逻辑处理之后最后生成的完整SQL语句，也就是说是攻击者的最终表现形态，已经撕去了大量的伪装。由于看到的是缺乏变化的最终形态，使数据库防火墙可以比较Web防火墙采用更加积极的防御策略，比如守白知黑策略进行异常SQL行为检测，100％防御SQL注入攻击。即使简单采用和Web防火墙类似的黑名单策略，由于看到的信息使完整的最终信息，使其防御难度比较Web防火墙大幅度下降，防御效果自然会更好。

更多的访问通道

通过http服务应用访问数据库只是数据库访问中的一种通道和业务，还有大量的业务访问和http无关，这些http无关的业务自然就无法部署web防火墙，只能依赖于数据库防火墙来完成。