浅谈SQL注入防护，提升数据库安全

Posted 2021-04-11 全栈开发者社区

随着IT时代的发展，我们的生活越来越便捷，高速信息时代让我们能实现数据的互联互通、信息资源的共享，这就是我们所说的信息技术时代；而随着大数据、云计算等技术的不断兴起与成熟，在大数据时代下的我们体验的是消费行为的智能化，商业价值的数字化，DT数据技术时代的到来让我们数据产生巨大价值的同时，也带来了许多高危风险。

跟我们日常息息相关的一些新闻，比如说某电商因为用户信息泄露，导致用户流量大减，品牌造成很大的负面影响；某高校新生信息被泄密，不法分子通过精准信息进行诈骗，骗走新生全家多年积攒的学费致使新生猝死等事件频发。从事件的本质来看，这些客户的业务均遭受到了攻击，发生了数据泄露。通过Verizon近几年来企业安全威胁报告我们可以看出，作为数据库的安全威胁越来越高。如何有效的提升数据库的安全成为大家最为关注的重点，数据安全也因此排在了2018年信息安全十大热词之首。

引：Verizon 2018数据泄露调查报告

一、数据库安全威胁分析

疑问同时也出现了，各大电商企业、金融单位、政府信息中心通过多年的IT建设，各安全设备已经部署很完善了。从边界安全、过程控制、内容审计等多方面进行防护，安全服务团队定期进行漏洞扫描、安全加固等动作，为什么在立体式的防护过程中，数据库还是被拖走了呢，而且在很多情况下是被长时间的、悄无痕迹的窃取掉呢?

从两个角度来分析：

第一，从IT建设发展的历程分析。目前大部分客户，在对安全体系的设计和治理方案中，主要依靠传统边界安全防护，如防火墙、下一代防火墙、IPS、IDS等安全控制类产品；随着边界安全防护的进一步落地，逐步开始向内容安全防护过度，如上网行为管理、堡垒机、数据库审计等安全设备；而随着数据大集中之后，数据库里的数据越来越有价值，而目前的防护体系中针对数据库的安全防护是空白的。很多客户认为自己有灾备软件、有数据库审计就能对数据库进行安全管理，但实际上灾备软件只能恢复数据库原有数据，数据库审计只能事后对访问情况进行追溯，如果业务系统存在SQL注入漏洞，恶意攻击者就可以通过绕过WAF等行为对数据库造成攻击，客户无法实时保障数据不被窃取或篡改，无法做到针对数据库的事前预防和事中阻断。

第二，从目前信息安全等级保护整改遗留的难点分析。等级保护整改中涉及物理安全、网络安全、服务器安全、制度安全等各部分的整改，相对来说通过技术、制度、传统安全设备的配置可以较快速和稳妥的进行加固。但是在数据库安全、应用系统安全上的安全加固以及整改却成棘手之事。不同的数据库以及各版本都有漏洞，但由于业务系统的长时间不间断运行，担心由于补丁及版本升级造成业务瘫痪，故把这部分的安全问题暂时搁置；另外，由于应用系统开发商已经把业务系统交付多年，虽然代码层面可能留有一些漏洞，但是让项目组重新对代码进行加固，阻力和压力都是很大的。由于这些问题的存在，数据库的大门一直向黑客敞开着。不是目前的防护体系已经把核心资产保护的水泄不通，而是黑客目前还没盯上你。

二、传统安全防护弊端

防火墙等设备主要是基于网络层的访问控制，很难对数据库协议以及应用层协议作出分析与控制；就算近几年发展的如火如荼的下一代防火墙，也很难对数据库协议进行精准解码并且作出实时阻断；IPS、IDS主要也是对边界攻击进行扫描分析，数据库层面的分析也很难进行控制；再分析一下web应用防火墙，其主要是通过规则库的方式来进行攻击拦截，而目前很多Oday攻击、SQL注入攻击等方式，都可以绕开WAF直接对数据库进行拖库。传统的安全防护手段是无法解决数据库安全的问题。

三、精准拦截SQL注入攻击，提升数据库安全

在数据库的众多威胁中，业务系统遭到SQL注入攻击，导致数据库拖库应该是最大的威胁，没有之一。而SQL注入攻击是广泛存在的，其攻击手段隐蔽、特征不可穷举、攻击手段平民化，这些特点也让其安全防护者头痛。可以说，只要人类还在编写数据库应用，就存在SQL注入漏洞的威胁。

正常的业务访问是使用者按照正常的访问方式进行，应用服务器把前端的请求转换成SQL语句与数据库进行交互。而恶意的业务访问是恶意攻击者构建非正常的SQL语句，把非业务正常访问的SQL语句想法设法的传递到数据库，并执行。

通过对业务中间件和数据库的交互分析会发现，当一个应用系统开发完交付的那一刻起，其正常的业务交互逻辑或语法就已经固化下来。既然能分析，那是否可以把这些SQL固化掉，建立一套防护规则呢？答案是肯定的。任何语句的交互，均有固定的语法规则。根据对语法规则的分析、归纳、整理、输出，完全可以对固有的业务访问进行固化处理。然而业务的访问量、访问路径、访问时间等均无法控制，必须引入机器学习，让系统具备自动学习的功能，并加以人工辅助。使之学习、分析并收敛成为固定的固执。暂且称之为自动化建模吧。当建模完成后，进入防护状态，恶意攻击的方法或手段的结果就是破坏了正常的业务交互行为，不在已完成的模态化的规则内，就可以做到及时的发现与阻断。在解决其方法的技术上，通过对业务SQL语句的关键字、逻辑关系等特征自动采样学习，并结合高性能的SQL语义分析计算，构建对应的SQL语法树，完成模态数据建模。在实际应用环境中，海量的数据主要包括以下三种数据：业务数据、运维数据、非法数据；而数据量占比最大的就是正常的业务数据。通过自动化学习，可以把正常的业务模态化数据流分离出来，把存在恶意攻击的语句识别出来。

图：建模及SQL注入防护

要做到这点就需要有大量的技术基础的，比如：数据库是在IT系统的最后端，前端所有的数据都要汇总过来，实际情况下就存在着大数据的并发。网络中数据包是杂乱无序进行传播的，需要通过流会话技术把数据包进行重组，使其成为有序传播的会话。若重组技术不成熟，将出现各种丢包、错组的情况，给数据库防护带来灾难。

做这些的前提就是对各数据库的传输协议能够完整的解析。相比IP协议不同，各个数据库厂商都有自己的私有协议，且各家数据库厂商未公开，更不要说向国内安全厂商公开。解码工作就是翻译，如果协议解码不全，就像打战一样根本无法获取清楚的情报，基于解码不全的任何防护和方案都是空谈。协议解码，只能靠笨办法，靠工程的积累，靠人力的分析和逆向，没有捷径好走。

以Oracle数据库为例分析，Oracle数据库通信采用TNS协议，其协议传输可以采用多种协议进行传输。应用程序与数据库进行连接的时候，首先会发送一个连接结构，之后数据库会返回一个重定向包，随后应用程序会从重定向的端口向服务器发送连接，服务器连接成功则返回接收包，新建立会话。随后，应用程序便可向数据库发送数据包进行相关SQL操作。当接收到应用程序传来的数据后，先对其进行TNS解码，然后解码出各个字段。（具体过程和协议分析，详见oracle官网，此处不在赘述）

另外，就是有效的部署和阻断。根据业务环境的不同必需要支持串联和并联接入到数据库的网络环境中去，才能做到很好的防范。当业务流量经历时，要及时准确的分析并识别数据库通讯协议以及SQL操作语句，进行应用层的协议解码，通过流会话解码技术，对数据库通讯协议进行流重组，所有解析语句都会标记唯一的会话标识，然后提取出数据库交互的SQL语句与已建立的业务模型进行匹配，进行规则策略的处理。若检查到SQL语句不符合模态化规则策略，都会触发后续的动作处理。根据部署及配置的处理动作不同采用不同处理办法，串联时规则处理动作采用“丢弃+RST阻断”实现方式，并联采用“RST阻断”实现方式。并且需要每次规则处理均采用流标标记跟踪每一个数据包，流一旦标记为阻断，对于与此流相关联的后续每一个网络包，都将触发阻断操作，以便彻底阻断业务连接数据库服务，避免无法阻断网络联接导致策略无效事件发生。

举个例子：恶意攻击者通过非法途径获得中间件Webshell，通过其发起的对数据库的交互，无论是账号、密码、IP来源都是相同的，不同的地方可能是使用后台木马作为连接工具或直接SQL语句来进行数据库攻击。通过已经自动的SQL语法建模以及来自多维度的准入因子识别技术，就可以把恶意攻击挡在数据库安全防护大门之外。

简单的说，就如我们小时候在村口池塘抓鱼，先放水，再抓鱼。只有通过识别海量正常的业务流使其放行，抓取所关注的恶意攻击语句，才能一劳永逸的解决数据库的威胁。

业务访问因素较多、难控制。过了中间件后，数据库的访问相对可控，相对可量化。换个思路，也许就有新的防护方案与效果。

变是常态，不变才是非常态。

喜欢就点一下「好看」呗~