(1)检查为共享环境中的客户提供的、便于他们更新和管理内容与功能的访问机制。考虑以下问题。
远程访问机制是否使用一个安全的协议与经过适当强化的基础架构?
客户是否能够访问他们正常情况下不能访问的文件、数据及其他资源?
客户是否能够在主机环境中获得一个交互式的shell,并执行任意命令?
(2)如果使用一个所有权应用程序,以方便客户配置和定制共享环境,考虑是否能够以这个应用程序为攻击目标,攻破该环境本身及其中运行的所有应用程序。
(3)如果能够在某个应用程序中执行命令、注入SQL脚本或访问任意文件,仔细研究,看是否能够以此扩大攻击范围,攻破其他应用程序。
(4)如果渗透测试员正在攻击一个使用ASP主机的应用程序,且该应用程序由许多共享与定制组件构成,确定其中的任何共享组件,如日志机制、管理功能以及数据库代码组件,尝试利用这些组件攻破应用程序的共享部分,进而攻破其他应用程序。
(5)如果所有共享环境使用一个常用的数据库,使用NGSSquirrel之类的数据库扫描工具,对数据库配置、补丁级别、表结构以及许可进行全面审查。数据库安全模型中存在的任何缺陷都可以被加以利用,将攻击范围由一个应用程序扩大到另一个应用程序。
3.攻击云
基本上,热门词汇“云”是指越来越多地将应用程序、服务器、数据库和硬件外包给外部服务提供商。此外,它也指目前共享托管环境的高度虚拟化。
从广义上讲,云服务是指提供API、应用程序或用于客户交互的Web界面的基于因特网的按需服务。通常,云计算提供商会存储用户数据或处理业务逻辑来提供相关服务。从终端用户的角度看,传统的桌面应用程序将升级为基于云的应用程序,各种企业可能会用按需服务来替代所有服务器。
在迁移到云服务的过程中,缺乏控制是一个经常被提及的安全问题。与传统的服务器或桌面软件不同,用户没有办法提前评估特定云服务的安全性,而需要将管理服务和数据的所有责任交给第三方。对企业而言,他们需要将更多控制托付给某个环境,而该环境包含的风险却无法完全定性或量化。由于基于Web的平台并不像传统的客户端/服务器可下载的产品那样经过严格的测试,因此,在支持云服务的Web应用程序中发现的漏洞也往往不为人们所了解。
这种对缺乏控制的担心,与当前企业在选择托管服务提供商、或用户在选择Web邮件服务商时的担忧类似。但是,仅仅这种担忧并不能反映云计算带来的日益严重的安全风险。攻破一个传统的Web应用程序可能会影响到成千上万名个体用户,但攻破云服务却可能影响到成千上万名云订阅用户及其用户群体。虽然存在缺陷的访问控制会使攻击者能够未授权访问工作流程应用程序中的敏感文档,但在云自助服务应用程序中,这种缺陷可能会导致攻击者能够未授权访问服务器或服务器集群。利用管理后端门户云服务中的同一漏洞,攻击者甚至能够访问整个企业基础架构。
Web应用程序角度的云安全
由于定义不明确,每个云服务提供商的实施方式各不相同,因此并没有适用于所有云体系架构的漏洞列表。但是,我们仍然可以确定一些专门针对云计算体系架构的主要漏洞区域。
注解
关于云安全,人们经常提到的一种防御机制是静态或动态数据加密。但是,在这种情况下,加密只能提供最低限度的保护。如17.1节所述,如果攻击者避开应用程序的身份验证或授权检查,针对数据提出看似合法的请求,栈中的组件就会自动调用任何解密功能。
克隆系统
在使用熵生成随机数字时,许多应用程序依赖操作系统的功能来执行这一操作。常用的熵源大多与系统本身的功能有关,如系统正常运行时间,或有关系统硬件的信息。如果系统被克隆,拥有其中一个克隆系统的攻击者就可以确定用于生成随机数字的熵源,这些信息又可用于更准确地预测随机数字发生器的状态。
将管理工具迁移到云中
用于配置和监视服务器的界面是企业云计算服务的核心应用。对用户而言,该界面是一个自助环境,通常是最初用于内部服务器管理的工具的Web版本。以前连接到网络的独立工具往往缺乏可靠的会话管理和访问控制机制,在没有预先采用基于角色的隔离的情况下更是如此。笔者曾发现一些将令牌或GUID用于服务器访问的情况。在其他情况下,应用程序仅仅通过序列化接口来调用任何管理方法。
功能优先的方法
和大多数新技术一样,云服务提供商采用功能优先的方法来吸引新用户。从企业的角度来看,云环境几乎总是通过自助Web应用程序管理。用户获得一系列用户友好的方法,并通过这些方法来访问数据。云服务通常并不提供功能“退出”机制。
用户需要定期调用大量云资源,为此,用户需要在客户端上存储一个永久身份验证令牌,以免输入密码,并用于标识设备(相对于用户)。如果攻击者能够访问该令牌,就可以借此访问用户的云资源。
Web存储
Web存储是云计算吸引终端用户的优势之一。为发挥效率,Web存储必须支持某种标准的浏览器或浏览器扩展、一系列技术和HTTP扩展(如WebDAV),并且通常需要支持存入缓存或基于令牌的证书(如上所述)。
此外,域上的Web服务器通常可以通过因特网访问。如果某个用户可以上传HTML文件并诱使其他用户访问其上传的文件,他就可以攻破这些使用同一服务的用户。与此类似,攻击者可以利用Java同源策略并上传一个JAR文件,从而在该文件被因特网上的其他位置调用时实现完全的双向交互。
由于使用相同工具的客户可能怀有恶意企图,以及不知情的客户可能无意中在环境中引入漏洞,因此,共享环境给应用程序安全带来了新的威胁。为解决这种双重威胁,设计共享环境时必须仔细处理客户访问、隔离与信任关系,并实施并不直接适用于单主机应用程序的控制。
1.保障客户访问的安全
无论向客户提供何种机制来帮助他们维护自己控制的内容,都应防止这种机制被第三方和恶意客户未授权访问。
远程访问机制应实施严格的身份确认,使用难以窃听的加密技术,并进行充分的安全强化。
仅准予个体用户最低的访问权限。例如,如果一名客户需要向一台虚拟主机服务器上传脚本,就应仅向他分配读取与写入他自己的文档根目录的访问权限。如果需要访问一个共享数据库,就应使用一个无法访问属于其他客户的数据或其他组件的低权限账户进行访问。
如果使用一个定制的应用程序提供客户访问,该应用程序必须满足严格的安全需求,并根据它在保护共享环境安全中发挥的作用进行测试。
2.隔离客户功能
不能信任共享环境中的客户,认为他们仅建立没有漏洞的无害功能。因此,稳定可靠的解决方案是应使用本章前半部分描述的架构控制来保护共享环境及其客户,避免受到通过不当内容实施的攻击。这要求隔离给予每名客户的功能,确保将任何有意或无意攻击的影响限制在局部,使其不会伤害其他客户。
每名客户的应用程序应使用一个独立的操作系统账户访问文件系统,该账户仅拥有读取与写入应用程序文件路径的权限。
强大系统功能与命令的访问权限应仅限于操作系统等级,且应只分配所需的最低权限。
应在任何共享数据库中实施相同的保护措施。应为每名客户使用一个单独的数据库实例,仅向客户分配低权限的账户,只允许他们访问自己的数据。
注解
许多基于LAMP模型的共享主机环境依靠PHP安全模式来限制某个恶意或易受攻击脚本的潜在影响。这种模式防止PHP脚本访问某些强大的PHP函数,将对其他函数的操作实施限制(请参阅第19章了解相关内容)。然而,这些限制并非完全有效,而且非常容易避开。虽然安全模式能够提供有用的防御,但由于它需要操作系统信任应用程序层,以控制它的操作,因此,从架构上讲,在这里控制恶意或易受攻击的应用程序造成的影响并不合适。由于这个及其他原因,PHP 6以后的版本删除了安全模式。
提示
如果能够在服务器上执行任意PHP命令,可使用phpinfo()命令返回PHP环境的配置信息。可以检查这些信息,了解PHP是否激活安全模式,以及其他配置选项如何影响执行的操作。请参阅第19章了解更多详情。
3.隔离共享应用程序中的组件
在ASP环境中,应用程序包含各种共享与定制的组件,这时应在各方控制的组件之间实施信任边界。如果一个数据库存储过程之类的共享组件接收从某一名客户的定制组件发出的数据,那么就不应信任这些数据,就好像它们是由终端用户送出的一样。每个组件都应对它的信任边界以外的相邻组件进行严格的安全测试,确定其中存在的、攻击者可以利用易受攻击的组件或恶意组件攻破其他应用程序的漏洞。应特别注意共享日志与管理功能。