NoSQL注入的分析和缓解(5)

针对代码的最佳实践.建议充分利用已经经受过安全验证处理的共享类库,从而减少犯安全性错误的机会.例如,使用针对认证充分验证过的类库,减少开发人员自己实现认证把漏洞引入到算法中的风险.再举一个使用“消毒后(sanitization)”类库的例子.所有注入攻击都是缺乏消毒造成的.使用一个充分测试消毒过的类库能很大程度上减少以自主研发消毒方法引入漏洞的风险.

特权隔离.在过去,NoSQL不支持适当的认证和角色管理9.现在,在大多数流行的NoSQL数据库上进行适当的认证管理和基于角色的访问控制认证已经成为可能.这些机制出于两个原因非常重要.第一,它们允许实施最少特权的原则,从而避免通过合法用户的特权升级攻击.第二,类似于SQL注入攻击10,当数据存储暴露在我们本文所说的注入攻击之下时,适当的特权隔离能将危害最小化.

安全扫描.建议在应用或源码上运行动态和静态应用安全测试(分别为DAST和SAST)以发现注入漏洞.问题是目前市场上的许多工具缺乏检测NoSQL注入的规则.DAST方法被认为比SAST更可靠11.特别是如果用户使用后端检查方法提升检测可靠性的话,这是一种作为交互式应用安全测试提出的方法9,12.它还建议,集成这些扫描工具到持续构建和发布系统中,如此它们就会在每个周期或检入时执行,缺陷就会及时发现并修复,而不只是在安全测试阶段.

由于两个原因,这可能会减少修复安全性缺陷的工作量.第一个,在开发阶段修复缺陷的成本要远低于生命周期更后的阶段,特别是因为安全性测试往往都在功能性测试之后,而且修复安全性缺陷可能会需要重新做功能性测试.第二个,开发人员能在早期了解这些缺陷,在之后的代码开发中不会犯类似的错误.

安全性测试.应该由专业的安全性测试人员测试应用.这些测试应该验证所有在设计阶段定义的安全需求都已经得到满足,并应该包括应用和主机基础设施之上(建议尽可能与生产环境类似)的浸透测试.

安全的部署

保持应用一个很重要的部分是确保安全的部署.如果部署不够安全,所有在应用代码层的安全性努力可能也就付之东流了.而这一阶段有时会被忽视.

网络隔离.Adobe、RSA Security和Sony等企业遭受了无数的攻击,在这些攻击中内网安全的概念已不再成立.内部网络在某种情况下是渗透的边界,我们应尽可能让攻击者很难从这一点上得到什么.对于某些相对较新缺乏基于角色授权的NoSQL数据库来讲这一点尤其如此.为此,建议严格配置网络,确保数据库只能由相关主机访问,比如应用服务器.

API的防护.为缓解REST API暴露和CSRF攻击的风险,需要对请求加以控制,限制它们的格式.例如,CouchDB已经采用了一些重要的安全措施去缓解因为暴露的REST API导致的风险.这些措施包括只接受JSON内容格式.HTML表单限制为URL编码的内容格式,所以攻击者不能使用HTML进行CSRF攻击.另一项举措是使用Ajax请求,得益于同源策略从浏览器发起的请求会被阻止.要确保在服务器的API中已经取消了JSONP和跨域资源共享,不能从浏览器直接发起操作,这一点也很重要.某些数据库,比如MongoDB,有很多第三方的REST API,其中许多都缺乏我们在此提到的安全措施.

监控和攻击检测

人类容易犯错,即使遵循所有安全开发最佳实践,仍有可能在开发完后从软件中找到漏洞.此外,在开发测试时未知的新的攻击途径可能会被发掘出来.因此,建议在运行期进行应用的监控和防御.尽管这些系统可能擅于发现和阻止某些攻击,但是它们不了解应用逻辑和那些假定运行的应用下的规则,所以它们不能找出所有的漏洞.

Web应用防火墙.Web应用防火墙(WAFs)是检查HTTP数据流和检测恶意HTTP事务的安全性工具.它们可以作为电器、网络嗅探器、代理或网站服务器模块来实现,具体目标是为Web应用提供一个独立的安全层,检测SQL注入之类的攻击.尽管已知攻击可以绕过防火墙13,但我们仍然提倡为这些系统增加检测NoSQL注入的规则.

侵入检测系统.与可以在网络层检测攻击的防火墙类似,基于主机的侵入检测系统(HIDSs)监控着应用的执行和服务器上的负载.HIDSs通常了解应用的正常行为,对与预期行为不符的行为给出预警,它们可能是攻击.此类工具可以检测在操作系统上传播的漏洞,但和SQL检测或CSRF无关.

数据活动监控.数据活动监控工具已成为组织数据防护的常规需求.它们控制数据的访问,以自定义安全预警监控活动,并创建数据访问和安全事件审计报告.虽然大多数解决方案定位的都是关系型数据库,但针对NoSQL数据存储的监控也已经开始涌现出来了10.我们希望这些将不断地改进成为NoSQL活动监控的常规实践.针对我们在本文演示过的注入攻击,这些工具是非常有用的监控和检测系统.

安全信息与事件管理(SIEM)系统和威胁警报.安全信息和事件管理系统整理日志并梳理日志的关联关系去帮助攻击的检测.

此外,威胁警报工具可以帮助提供恶意IP地址和域上的数据,以及有危害的其他指标,这能有助于检测注入.

运行期应用自我保护(RASP).运行期应用自我保护引入了一种新的应用安全方式,在此防御机制是在运行期嵌入到应用中的,使其可以进行自我监控.运行期应用自我保护的优点超过其他安全技术,因为它能够检查内部的程序流转和数据处理.在应用中的关键位置设置检查点能更精确地检测更多的问题.而不利的一面是,运行期应用自我保护付出了性能的代价,它高度依赖于编程语言,而且可能导致应用在生产环境中中止运行.

NoSQL数据库遭受像传统数据库一相的风险问题.一些低层技术和协议已经变了,但注入风险、不正确的访问控制管理以及不安全的网络暴露仍然居高不下.我们建议使用具有内置安全措施的成熟的数据库.然而,即使使用最安全的数据存储也无法阻止利用Web应用中的漏洞去访问数据存储的注入攻击.避免这些问题的其中一种方法是通过谨慎的代码检查和静态分析.然而,这些很难实施并且可能有很高的误报率.尽管动态分析工具已表明对检测SQL注入攻击很有作用,但它们需要做出调整去检测我们在本文中所说的那些特定于NoSQL数据库的漏洞.此外,与NoSQL风险相关的监控和防御系统也应该利用起来

（编辑：ASP站长网）