9,506
社区成员
发帖
与我相关
我的任务
分享为什么WAF（Web Application Firewall）不能确保数据库安全？
警告：不要认为有了WAF的保护，数据库安全就可以高枕无忧了，数据库仍然有很大的暴露风险。
Web应用程序防火墙（WAF）现在已经成为很多商业Web网站和系统的基本保护措施了，它的确在防范很多针对Web系统的安全攻击有比较好的效果，但是WAF在面对攻击方式多种多样的SQL注入方面还是显得束手无策。
背景知识：什么是WAF？
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注入攻击的防护作用越来越小。
多维度数据库保护是完全之策
既然数据库的方面途径很多，要想比较好的解决数据泄露的的危险，多维度防护是最佳方法，只有堵住每条可能泄露的攻击才能确保数据库的安全，可能的方法包括但不仅限于：
1. 运行时应用程序自我保护（RASP）
2. 数据库防火墙
3. 模式学习过程
4. 职责分离
5. 风险为基础的政策
6. 敏感信息屏蔽
7. 定期审计管理和访问敏感信息
运行时应用程序自我保护（RASP）
RASP针对应用程序保护的，不仅仅是对Web应用测试，它将代码扫描工具的漏洞发现功能和WAF的实时攻击拦截能力结合起来，将这些防护功能像疫苗一样注入到应用程序中，让应用程序像人体拥有疫苗一样对攻击拥有免疫能力，他可以找到所有已知漏洞，像一个虚拟的大补丁将所有的已知漏洞修补起来，免于大多数漏洞攻击，同时它和应用程序一起运行是同一个进程，拥有应用程序的上下文，了解应用程序的每一个动作，因此他能精确的了解每一个攻击并能够实时对攻击进行防御。比如SQL注入，它在每个数据库的JDBC的statement具体实现里，根据对每个数据的不同，有针对性的将SQL注入保护程序注入，这样就能确保各种可能的SQL注入攻击得到有效的防范，并且这个防护是在应用程序访问数据库的必经之路，是不可绕过的。这两个优势是WAF无法企及的。如果每个应用程序都进行RASP保护，至少无论内外通过应用进行SQL注入基本上是不可能的，这样就可以堵住应用程序访问数据库的漏洞。目前RASP是比较新的概念，国外有HP在做，国内好像有一个初创安全OneASP在做类似的产品，大家有有兴趣可以关注一下。
数据库防火墙
数据库防火墙技术是针对关系型数据库保护需求应运而生的一种数据库安全主动防御技术，数据库防火墙部署于应用服务器和数据库之间。用户必须通过该系统才能对数据库进行访问或管理。数据库防火墙所采用的主动防御技术能够主动实时监控、识别、告警、阻挡绕过企业网络边界（FireWall、IDS\IPS等）防护的外部数据攻击、来自于内部的高权限用户（DBA、开发人员、第三方外包服务提供商）的数据窃取、破坏、损坏的等，从数据库SQL语句精细化控制的技术层面，提供一种主动安全防御措施。
模式匹配学习过程
基于自学习机制的风险管控模型，主动监控数据库活动，防止未授权的数据库访问、SQL注入、权限或角色升级，以及对敏感数据的非法访问等。
基于风险管理的策略
任何类型的数据库查询语句或命令，都可以用一些方法来评估。影响风险评估的因素包括白名单和黑名单，命令是从哪里过来的，在一定时间有多少个类似的命令等等，利用所有的信息，一个基于规则的系统可以使用这些信息来通过一系列的规则来评估那些命令是可疑的。
权责分明
为数据库访问分配适当的权限是非常必要的。基于Web的应用程序只应该有有限的查询权限，数据库管理员拥有更大的管理权限是有必要的。通过适当的执行职责分离，可以有效的避免多种数据库攻击。
混淆敏感数据
所有人都应该能查看敏感数据，甚至包括数据库管理员，程序员，以及高管。DBA可以执行一些数据库管理任务，但是没有必要让他们能看到数据库中个人的敏感数据，为了达到这个目的，使用一个非常强大的和实时的数据混淆解决方案是非常重要的。一些组织使用离线的“生产”系统进行屏蔽，但随着实时数据的混淆的成熟，实时数据混淆系统在成本和避免数据更新方面有更大的优势，所有改变都可以实时在数据库中体现。
定时审计对敏感数据的管理和访问行为
一致的和可靠的审计过程中，寻找可疑的活动和更新政策，不断提高数据库安全有很长的路要走。今天的数据库安全产品可以根据可定制的规则对某些种类的访问提供警报服务。
让每个公司都能保护得起数据库安全
在以前数据库安全保护只有少数大公司能够花大价钱才能搞好，数据库防火墙非常昂贵，制定规则，审计行为都需要大量的人力去解决，小公司基本没有能力去做。现在RASP是一种非常好的解决方案，只要制定简单规则，比如只有管理员能访问生产数据库等，其他所有数据库访问都通过应用程序访问，而每个应用程序都安装RASP保护程序，这样数据库的安全是有保障的。
Web应用程序防火墙（WAF）现在已经成为很多商业Web网站和系统的基本保护措施了，它的确在防范很多针对Web系统的安全攻击有比较好的效果，但是WAF在面对攻击方式多种多样的SQL注入方面还是显得束手无策。
背景知识：什么是WAF？
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注入攻击的防护作用越来越小。
多维度数据库保护是完全之策
既然数据库的方面途径很多，要想比较好的解决数据泄露的的危险，多维度防护是最佳方法，只有堵住每条可能泄露的攻击才能确保数据库的安全，可能的方法包括但不仅限于：
1. 运行时应用程序自我保护（RASP）
2. 数据库防火墙
3. 模式学习过程
4. 职责分离
5. 风险为基础的政策
6. 敏感信息屏蔽
7. 定期审计管理和访问敏感信息
运行时应用程序自我保护（RASP）
RASP针对应用程序保护的，不仅仅是对Web应用测试，它将代码扫描工具的漏洞发现功能和WAF的实时攻击拦截能力结合起来，将这些防护功能像疫苗一样注入到应用程序中，让应用程序像人体拥有疫苗一样对攻击拥有免疫能力，他可以找到所有已知漏洞，像一个虚拟的大补丁将所有的已知漏洞修补起来，免于大多数漏洞攻击，同时它和应用程序一起运行是同一个进程，拥有应用程序的上下文，了解应用程序的每一个动作，因此他能精确的了解每一个攻击并能够实时对攻击进行防御。比如SQL注入，它在每个数据库的JDBC的statement具体实现里，根据对每个数据的不同，有针对性的将SQL注入保护程序注入，这样就能确保各种可能的SQL注入攻击得到有效的防范，并且这个防护是在应用程序访问数据库的必经之路，是不可绕过的。这两个优势是WAF无法企及的。如果每个应用程序都进行RASP保护，至少无论内外通过应用进行SQL注入基本上是不可能的，这样就可以堵住应用程序访问数据库的漏洞。目前RASP是比较新的概念，国外有HP在做，国内好像有一个初创安全OneASP在做类似的产品，大家有有兴趣可以关注一下。
数据库防火墙
数据库防火墙技术是针对关系型数据库保护需求应运而生的一种数据库安全主动防御技术，数据库防火墙部署于应用服务器和数据库之间。用户必须通过该系统才能对数据库进行访问或管理。数据库防火墙所采用的主动防御技术能够主动实时监控、识别、告警、阻挡绕过企业网络边界（FireWall、IDS\IPS等）防护的外部数据攻击、来自于内部的高权限用户（DBA、开发人员、第三方外包服务提供商）的数据窃取、破坏、损坏的等，从数据库SQL语句精细化控制的技术层面，提供一种主动安全防御措施。
模式匹配学习过程
基于自学习机制的风险管控模型，主动监控数据库活动，防止未授权的数据库访问、SQL注入、权限或角色升级，以及对敏感数据的非法访问等。
基于风险管理的策略
任何类型的数据库查询语句或命令，都可以用一些方法来评估。影响风险评估的因素包括白名单和黑名单，命令是从哪里过来的，在一定时间有多少个类似的命令等等，利用所有的信息，一个基于规则的系统可以使用这些信息来通过一系列的规则来评估那些命令是可疑的。
权责分明
为数据库访问分配适当的权限是非常必要的。基于Web的应用程序只应该有有限的查询权限，数据库管理员拥有更大的管理权限是有必要的。通过适当的执行职责分离，可以有效的避免多种数据库攻击。
混淆敏感数据
所有人都应该能查看敏感数据，甚至包括数据库管理员，程序员，以及高管。DBA可以执行一些数据库管理任务，但是没有必要让他们能看到数据库中个人的敏感数据，为了达到这个目的，使用一个非常强大的和实时的数据混淆解决方案是非常重要的。一些组织使用离线的“生产”系统进行屏蔽，但随着实时数据的混淆的成熟，实时数据混淆系统在成本和避免数据更新方面有更大的优势，所有改变都可以实时在数据库中体现。
定时审计对敏感数据的管理和访问行为
一致的和可靠的审计过程中，寻找可疑的活动和更新政策，不断提高数据库安全有很长的路要走。今天的数据库安全产品可以根据可定制的规则对某些种类的访问提供警报服务。
让每个公司都能保护得起数据库安全
在以前数据库安全保护只有少数大公司能够花大价钱才能搞好，数据库防火墙非常昂贵，制定规则，审计行为都需要大量的人力去解决，小公司基本没有能力去做。现在RASP是一种非常好的解决方案，只要制定简单规则，比如只有管理员能访问生产数据库等，其他所有数据库访问都通过应用程序访问，而每个应用程序都安装RASP保护程序，这样数据库的安全是有保障的。
...全文
请发表友善的回复…
发表回复
