NoSQL注入的分析和缓解

这个示例展示了Memcached的典型用法,在处理输入之前首先检查在数据库中是不是已经存在了.假设用类似代码检查从用户那里接收的认证令牌,验证他们是不是登录过了,那么就可以通过传递以下作为令牌的字符串来利用它(注入部分已经加粗强调)：

当这个字符串作为令牌传递时,数据库将检查这个“random_token”是否存在,然后将添加一个具有“root”值的“my_crafted_token”.之后,攻击者就可以发送具有root身份的my_crafted_token令牌了.

可以被这项技术攻击的其他指令还有：

在此,incr用于增加一个键的值,decr用于缩减一个键的值,以及delete用于删除一个键.攻击者也可以用像set和get函数一样的手段来使用带来自己键参数的这三个函数.

攻击者可以使用多条目函数进行同样的注入：deleteMulti、getMulti和setMulti,其中每一个键字段都可以被注入.

回车换行注入可以被用于连接多个get请求.在一项我们进行的测试中,包括原始get在内最多可以连接17条.这样注入返回的结果是第一个键及其相应的值.

该驱动程序的漏洞已经在PHP 5.5 中修复,但不幸的是它已存在于之前所有的PHP版本中了.按照W3Techs.com对生产系统的PHP版本的统计来看,超过86%的PHP网站使用了比5.5要老的版本,这意味着如果他们使用了Memcached就很容易受到这种注入攻击.

跨域违规

NoSQL数据库的另一个常见特点是,他们能够常常暴露能够从客户端应用进行数据库查询的HTTP REST API.暴露REST API 的数据库包括MongoDB、CouchDB和HBase.暴露REST API 就直接把数据库暴露给应用了,甚至是仅基于HTML5的应用,因为它不再需要间接的驱动程序了,让任何编程语言都可以在数据库上执行HTTP查询.这么做的优势非常明显,但这一特点是否伴随着安全风险?我们的回答是肯定的：这种REST API给跨站点请求伪造(CSRF)暴露了数据库,让攻击者绕过了防火墙和其他外围防御.

只要数据库部署在诸如防火墙之类的安全设施之后的安全网络中,攻击者要危害这个数据库就必须找到能让他们进入这个安全网络的漏洞,或者完成能让他们执行任意查询的注入.当数据库在安全网络内暴露 REST API时,任何能够访问该安全网络的人都可以仅通过HTTP就能在这个数据库上执行查询,因此在浏览器上就可以发起此类查询了.如果攻击者可以在网站上输入HTML表单,或者欺骗用户到攻击者自己的网站上,就能够通过提交这个表单在数据库上执行任何post操作了.而post操作包括增加文件.

我们在调查研究审查了Sleepy Mongoose,这是一个针对MongoDB的全功能HTTP接口. Sleepy Mongoose API是以http:// {host name}/{db name}/{collection name}/{action}这样的URL格式定义的.查找文件的参数可以作为查询参数包含在内,而新文件也可以作为请求数据予以添加.例如,如果我们想要在safe.internal.db主机上的数据库中名为hr的管理员集合中增加一个新文件{username:’attacker’},就可以发送一个post HTTP请求至http://safe.internal.db/hr/admins/_insert,加上URL编码过的数据username=attacker.

现在让我们看看CSRF攻击是如何使用这个函数增加新文件到管理员集合中的,从而在hr数据库(它被认为处于安全的内部网络中)中增加了一个新的管理员用户,如图5所示.若想攻击成功,必须要满足几个条件.首先,攻击者必须能操作一个网站,要么是他们自己的网站,要么是利用不安全的网站.攻击在该网站放置一个HTML表单以及一段将自动提交该表单的脚本,比如：

图5 NoSQL HTTP REST API上的跨站请求背负式攻击示意图.

藏在防火墙后的内部网络内的用户被欺骗访问一个恶意外部网页,这将导致在内部网络的NoSQL数据库的 REST API 上执行非预期的查询.

第二,攻击者必须通过网络诱骗或感染用户经常访问的网站欺骗用户进入被感染的网站.最后,用户必须许可访问Mongoose HTTP接口.

用这种方式,攻击者不必进入内部网络即可执行操作,是插入新数据到位于内部网络中的数据库中.这种攻击执行很简单,但要求攻击者要提前侦察去识别主机、数据库名称,等等.

缓解

鉴于我们在本文中所提到的这些攻击手段,NoSQL部署中的安全问题的缓解是非常重要的.但不幸的是,应用层的代码分析不足以确保所有风险都能得以缓解.三个趋势使该问题将比之前面临更多的挑战.首先,云和大数据系统的形成,它们通常会执行多个复杂应用,这些应用使用异构的开源工具和平台.而这些应用通常由开源社区开发,大多数情况下,未经受过全面的安全性测试.另一个挑战是伴随DevOps方法论而形成的现代代码开发的速度,因为DevOps追求的是缩短开发和生产之间的时间.最后,大多数应用安全测试工具不能与新编程语言的应用保持同步,例如,大多数安全产品不支持Golang、Scala和 Haskel.

开发和测试

为充分解决由应用层引入的风险,我们需要考虑整个软件开发生命周期,如图6所示.

图6 应用和部署安全的生命周期.为充分解决由应用层引入的风险,我们需要考虑整个软件开发生命周期.

意识.很明显,构建阻止注入和其他潜在漏洞的安全软件是最好、最廉价的解决方案.建议在该软件生命周期中涉及到的人针对他们的职责接受适应的安全培训.例如,已经理解漏洞的开发人员就不太可能把它们引入到软件中.

设计.应用的安全方面必须在开发阶段早期予以考虑和定义.定义什么需要在应用内保护,如何确保这个功能已经转化为开发阶段中的任务并得到足够的重视.

（编辑：江门站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!