IT学习网 - 爱学习 - 最具影响力综合资讯网站 -- 中国IT界的领航者!
热门关键字:      88888  as  xxx
站外
广告
站外
广告

为什么 WAF 不能确保数据库安全?

发布时间:2015-12-06 14:26文章来源:未知文章作者: IT学习网点击次数:
Web 应用程序防火墙(WAF)现在已经成为许多商业 Web 网站与系统的基本保护措施,它的确在防范许多针对 Web 系统的安全攻击方面卓有成效,但是 WAF 在面对攻击方式多种多样的 SQL 注入方面还是显得束手无策。所以,不要以为有了 WAF 的保护,数据库安全就万

Web 应用程序防火墙(WAF)现在已经成为许多商业 Web 网站与系统的基本保护措施,它的确在防范许多针对 Web 系统的安全攻击方面卓有成效,但是 WAF 在面对攻击方式多种多样的 SQL 注入方面还是显得束手无策。所以,不要以为有了 WAF 的保护,数据库安全就万无一失了。事实上,数据库仍然存在很大的安全隐患。

背景知识:什么是 W AF? ‍

Web 应用防火墙(WAF)是一种基础的安全保护模块,主要针对 HTTP 访问的 Web 程序保护,部署在 Web 应用程序前面,在用户请求到达 Web 服务器前对用户请求进行扫描和过滤,分析并校验每个用户请求的网络包,确保每个用户请求有效且安全,对无效或有攻击行为的请求进行阻断或隔离。

WAF 可通过定义一些常见的 SQL 注入特征码对常见 SQL 注入攻击提供防护,比如 SQL 注入代码加入到某些命令或某些输入,这些 WAF 是没有问题的。但是市面上的关系型数据总类非常多,虽然有统一的 SQL 结构化数据查询语言,但是每个数据库的具体实现有非常多的差异,这些差异就导致了多种 SQL 注入攻击方式的产生。因此也就导致了像 WAF 这类安全保护系统在不理解应用程序的上下文,不熟悉数据库类型、命令、结构的情况下,仅仅通过分析网络数据包,加上定义一些数据库特殊字符黑名单,远远不足以防护多种多样的 SQL 注入攻击。

WAF 在 Web 应用安全防护方面的作用的确值得认可,它能有效防护多种 Web 攻击,每个企业都应该使用 WAF 为 Web 应用程序提供安全保障。但是,千万不要天真地以为,有了 WAF 你的数据库就安全了,这种想法非常的危险。

数据库暴露的访问点多种多样

从 WAF 的原理来看,WAF 并不能完全保护 Web 应用程序免受 SQL 注入攻击,因为它在 Web 应用程序外部,不了解应用程序的上下文,不知道目标数据库的类型,这就从根本上决定了 WAF 只能防范最常见的 SQL 注入方式。

即使 WAF 做的足够好,能够防范绝大多数从 Web 系统进入的 SQL 注入攻击,也不能断言数据库得到了全面的保护,因为能访问数据库的不仅仅是 Web 系统,还有许多其他途径。

除了 Web 系统外,还有三类主要的数据库访问途径:

1.组织内其他应用系统能访问数据库:比如在电子商务系统里,价格和库存可能会用一些自动化的脚本来定时更新。
2.一些内部管理程序可以访问系统,也可能是一些接口,方便雇员添加信息或者发送信息给客户。
3.还有就是数据库 DBA,IT 经理,QA,开发人员等等内部人员通过数据库管理工具可以访问数据库。

WAF 只监控通过 HTTP 方式来的数据,这些潜在的数据库访问源头 WAF 是毫不知情的,但是来自内部的攻击则更可怕。内部人员非常清楚数据库的结构和内容,目标性也更加明确,不是获取经济利益就是获取大量内部信息,造成的危害可以说是毁灭性的,比如前两年发生在银行客户数据库大规模泄露事件就很清晰地证明了这一点。同时现在黑客攻击手段越来越高明,翻墙技术已经非常成熟,而且在云时代有明显边界的网络拓扑结构越来越少。总之,WAF 对 SQL 注入攻击的防护作用越来越小。

多维度数据库保护是万全之策

既然数据库的访问途径很多,要想比较好的解决数据泄露的危险,多维度防护才是最佳方法,只有堵住每条可能泄露的攻击才能确保数据库的安全,可能的方法包括但不仅限于:

运行时应用程序自我保护(RASP)

1.数据库防火墙
2.模式学习过程
3.职责分离
4.风险为基础的政策
5.敏感信息屏蔽
6.定期审计管理和访问敏感信息

运行时应用程序自我保护(RASP)

RASP 针对应用程序保护的,不仅仅是对 Web 应用测试,它将代码扫描工具的漏洞发现功能和 WAF 的实时攻击拦截能力结合起来,将这些防护功能像疫苗一样注入到应用程序中,让应用程序像人体拥有疫苗一样。

对攻击拥有免疫能力,找到所有已知漏洞,像一个虚拟的大补丁一样修补所有已知漏洞,免于大多数漏洞攻击,同时它和应用程序一起运行同一个进程,拥有应用程序的上下文,了解应用程序的每一个动作,因此能精确了解每一个攻击并能够实时对攻击进行防御。比如 SQL 注入,它在每个数据库 JDBC 的 statement 具体实现里,根据每个不同的数据,有针对性地将 SQL 注入保护程序注入,这样就能确保各种可能的 SQL 注入攻击得到有效的防范,并且这个防护是在应用程序访问数据库的必经之路,是不可绕过的。这两个优势是 WAF 无法企及的。如果每个应用程序都进行 RASP 保护,至少无论内外通过应用进行 SQL 注入基本上是不可能的,这样就可以堵住应用程序访问数据库的漏洞。目前 RASP 是比较新的概念,国外有 HP 在做,国内有一个初创安全 OneRASP 在做类似的产品,有兴趣可以关注一下。

数据库防火墙

数据库防火墙技术是针对关系型数据库保护需求应运而生的一种数据库安全主动防御技术,数据库防火墙部署于应用服务器和数据库之间。用户必须通过该系统才能对数据库进行访问或管理。数据库防火墙所采用的主动防御技术能够主动实时监控、识别、告警、阻挡绕过企业网络边界(FireWall、IDS\IPS等)防护的外部数据攻击、来自于内部高权限用户(DBA、开发人员、第三方外包服务提供商)的数据窃取、破坏、损坏等,从数据库 SQL 语句精细化控制的技术层面,提供一种主动的安全防御措施。

模式匹配学习过程

基于自学习机制的风险管控模型,主动监控数据库活动,防止未授权的数据库访问、SQL 注入、权限或角色升级,与对敏感数据的非法访问等。

基于风险管理的策略

任何类型的数据库查询语句或命令,都可以用一些方法来评估。影响风险评估的因素包括白名单和黑名单,命令是从哪里过来的,在一定时间有多少个类似的命令等等,利用所有的信息,一个基于规则的系统可以借助一系列的规则来评估哪些命令是可疑的。

权责分明

为数据库访问分配适当的权限是非常必要的。基于 Web 的应用程序只应该有有限的查询权限,数据库管理员拥有更大的管理权限是有必要的。通过适当地执行职责分离,可以有效避免多种数据库攻击。

混淆敏感数据

所有人都应该能查看敏感数据,甚至包括数据库管理员,程序员,以及高管。DBA 可以执行一些数据库管理任务,但是没有必要让他们能看到数据库中个人的敏感数据,为了达到这个目的,使用一个非常强大的和实时的数据混淆解决方案是非常重要的。一些组织使用离线的“生产”系统进行屏蔽,但随着实时数据的混淆的成熟,实时数据混淆系统在成本和避免数据更新方面有更大的优势,所有改变都可以实时在数据库中体现。

定时审计对敏感数据的管理和访问行为

一致的和可靠的审计过程中,寻找可疑的活动和更新政策,不断提高数据库安全还有很长的路要走。今天的数据库安全产品可以根据可定制的规则对某些种类的访问提供警报服务。

让每个公司都能保护得起数据库安全

在以前,数据库安全保护只有少数大公司花大价钱才能搞好,数据库防火墙非常昂贵。制定规则,审计行为都需要大量的人力去解决,小公司基本没有能力去做。现在 RASP 是一种非常好的解决方案,只要制定简单规则,比如只有管理员能访问生产数据库等,其他所有数据库访问都通过应用程序进行,而每个应用程序都安装 RASP 保护程序,这样数据库的安全才是有保障的。


为什么 WAF 不能确保数据库安全?
本文由 IT学习网 整理,转载请注明“转自IT学习网”,并附上链接。
原文链接:http://www.ourlove520.com/Article/netsafe/qiye/149183.html

标签分类:

上一篇:上一篇:安全牛首次公开发布《网络安全体系设计方法论》
下一篇: 下一篇:刘强东:知识产权保护不力让企业进入恶性循环
无觅关联推荐,快速提升流量