当评估某个应用程序的安全状态时，Web应用程序架构经常被忽略，但实际上它是一个重要的安全领域。在常用的分层架构中，如果无法隔离不同的层次，攻击者就可以利用某个层次中的一个漏洞完全攻破其他层次，进而控制整个应用程序。
如果多个应用程序在相同的基础架构上运行，或者共享一个用途更广泛的支配型应用程序的公共组件，这些环境也会造成其他不同类型的安全威胁。在这些情况下，攻击者有时可能利用应用程序中的漏洞或恶意代码攻破整个环境以及其他属于不同客户的应用程序。最近流行的“云计算”增加了许多组织遭受此类攻击的可能性。
本章讨论一系列不同类型的架构配置，并说明如何利用应用程序架构中存在的缺陷扩大攻击范围。
许多Web应用程序使用多层架构，在这个架构中，应用程序用户界面、业务逻辑与数据存储分别位于不同的层次中，这些层次可能采用各种技术，并在不同的计算机上运行。一个常用的三层架构可分为以下层次：
展现层，执行应用程序的界面；
应用程序层，执行核心应用程序逻辑；
数据库层，存储并处理应用程序数据。
实际上，许多复杂的企业应用程序对不同层次进行更详细的划分。例如，一个基于 Java 的应用程序可能采用以下层次与技术：
应用程序服务器层（例如Tomcat）；
展现层（例如WebWork）；
授权与验证层（例如JAAS或ACEGI）；
核心应用程序框架（例如Struts或Spring）；
业务逻辑层（例如Enterprise Java Beans）；
数据库对象关系映射（例如Hibernate）；
数据库JDBC调用 ；
数据库服务器。
与单层设计相比，多层架构具有诸多优点。与大多数软件设计方法一样，将高度复杂的处理任务分解成简单、模块化的功能组件，能够显著改善应用程序开发管理并降低漏洞的发生率。拥有明确定义界面的独立组件可在不同的应用程序内及应用程序之间重复使用。不同的开发者可以并行开发不同的组件，而不必深入了解其他组件的执行细节。如果有必要替换一个层次使用的技术，替换过程也不会给其他层次造成严重影响。另外，如果运用合理，多层架构可显著改善整个应用程序的安全状态。
前面的分析结果表明，如果一个多层架构的执行过程存在缺陷，这些缺陷可能会引入安全漏洞。了解多层模型可帮助渗透测试员确定实施各种安全防御（如访问控制与输入确认）的位置，以及如何穿越层次边界来破坏这些防御，从而对Web应用程序实施有效攻击。设计不佳的分层架构可能受到以下3种类型的攻击。
可以利用不同层之间的信任关系扩大攻击范围，从一个层侵入到另一个层。
如果不同层之间没有完全隔离，就可以利用某一层存在的缺陷直接破坏另一层实施的安全保护。
局部攻破一个层后，就可以直接攻击其他层的基础架构，从而将攻击扩大到其他层。
下面逐一详细介绍这些攻击。
应用程序的不同层之间彼此信任，并以特殊的方式运转。如果应用程序运行正常，这些假设就有效。然而，在反常情况下或者应用程序正受到攻击时，上述假设就会被打破。这时渗透测试员就可以利用这些信任关系将攻击范围由一个层扩大到另一个层，增加安全违反的严重程度。
许多企业应用程序中存在一种十分常见的信任关系，即某个应用程序层专门负责管理用户访问。这个层实施验证与会话管理，并执行各种逻辑，决定是否准予某个特殊的请求。如果该应用程序层决定准予一个请求，它就向其他层发出相关命令，以执行被请求的操作。其他层相信准予请求的应用程序层，认为它已经实施了严格的访问控制检查，因而执行它们从该应用程序层收到的全部命令。
这种类型的信任关系会加速恶化我们在前面章节中讨论的许多常见的Web漏洞。如果应用程序中存在 SQL 注入漏洞，攻击者就可以利用它访问应用程序中的所有数据。即使应用程序并不以数据库管理员的身份访问数据库，它通常也会使用一个能够读取并更新所有应用程序数据的独立账户。因此，数据库层完全信任对它的数据实施访问控制的应用程序层。
同样，应用程序组件通常使用较高权限的操作系统账户运行，这些账户能够执行敏感操作并访问关键文件。在这种配置下，操作系统层完全信任相关应用程序层，认为它不会执行有害操作。如果攻击者发现一个命令注入漏洞，在利用它攻破应用程序层后，他们还可以进一步完全攻破为应用程序层提供支持的基础操作系统。
层之间的信任关系还可能导致其他问题。如果一个应用程序层存在编程错误，那么这些错误可能会导致其他层出现反常行为。例如，第 11 章描述的竞态条件导致后端数据库提供属于错误用户的账户信息。而且，如果管理员正在调查一起意外事件或安全违反行为，只通过查阅信任层中的审计日志通常并不足以帮助他们完全了解事件的整个发生过程，因为他们只能确定可信层是引发事件的媒介。例如，发生 SQL 注入攻击后，数据库日志可能会记录攻击者注入的每一个查询，但要确定哪一名用户是攻击者，还必须将这些事件与应用程序层中的日志记录进行交叉参考，因为通过日志记录无法确定攻击者。
如果应用程序的不同层之间没有完全隔离，那么攻破一个层的攻击者就可以直接破坏另一个层实施的安全保护，从而执行这个层负责控制的操作或访问其中的数据。
如果几个层在相同的计算机上执行，那么这时往往会出现漏洞。为节省成本，许多应用程序常常采用这种架构配置。
通常，为满足PCI等管理或法规要求，许多应用程序都会对敏感的用户数据进行加密，以最大限度地降低应用程序被攻破造成的影响。虽然可以对密码进行“加salt散列”处理，以确保即使数据存储被攻破，攻击者仍然无法确定密码，但对于应用程序需要将其恢复为明文值的数据，则需要采用不同的处理方法。关于这类数据，最常见的示例包括用户的安全问题（可以通过与服务台进行交互来确认）和支付卡信息（在付款时需要这些信息）。为此，需要采用某种双向加密算法。使用加密时出现的典型漏洞是：加密密钥与加密数据之间未进行逻辑隔离。在现有环境中使用加密时，一种简单但存在缺陷的隔离方法，是将算法和相关密钥置于数据层，以避免影响到其他代码。但是，如果数据层也被攻破（例如，通过SQL注入攻击），攻击者将可以轻松确定并执行解密功能。
注解 无论以何种方法进行加密，只要应用程序能够解密信息，并且应用程序被完全攻破，攻击者总是能够确定解密算法的逻辑路径。
许多小型应用程序使用一个LAMP服务器（运行Linux、Apache、MySQL 和 PHP 等开源软件的独立计算机）。在这种架构中，如果Web应用程序层中的一个文件泄露漏洞，其本身并不会造成严重的缺陷，但却可以导致攻击者无限制地访问应用程序的所有数据，因为MySQL数据保存在可读的文件中，且Web应用程序进程通常有权读取这些文件。即使数据库对它的数据实施了严格的访问控制，而且应用程序使用一系列低权限的账户连接数据库，但如果攻击者能够直接访问保存在数据库层中的数据，他仍然可以完全避开这些保护。
例如，图17-1所示的应用程序允许用户选择一种皮肤，自定义他们的使用体验。这要求用户选择一个层叠样式表（Cascading Style Sheet，CSS）文件，并且应用程序会将这个文件呈现给用户审查。
图17-1 一个包含查看选中文件功能的应用程序
如果这个功能包含一个路径遍历漏洞（请参阅第10章了解相关内容），那么攻击者就可以利用这个漏洞直接访问保存在MySQL数据库中的任意数据，从而破坏在数据库层实施的访问控制。图17-2显示了一个从MySQL用户表中成功获取用户名和密码散列的攻击。
图17-2 一个破坏数据库层，获取任意数据的攻击
提示 如果攻击者具有文件写入访问权限，就可以尝试对应用程序的配置或托管的虚拟目录执行写入操作，以执行相关命令。请参阅第10章的nslookup示例。
许多语言都包含用于在当前脚本中包含本地文件的函数。如果攻击者能够指定文件系统上的任何文件，这无疑是一个严重的问题。此类文件可能为/etc/passwd文件或包含密码的配置文件。很明显，这些情况会导致信息披露，但攻击者不一定能够扩大攻击范围，以进一步攻破整个系统（如第10章所述，通过远程文件包含无法达到这一目的）。不过，攻击者仍然可以利用其他应用程序或平台功能，通过包含一个内容部分受其控制的文件来执行命令。
例如，某应用程序在以下URL的country参数中提交用户输入：
http://eis/mdsecportal/prefs/preference_2?country=en-gb
用户可以修改country参数来包含任意文件。一个可能的攻击是，请求包含脚本命令的URL，以便将这些命令写入Web服务器日志文件，然后使用本地文件包含行为包含这个日志文件。
一种利用PHP体系架构怪癖的有趣方法，是以明文形式将PHP会话变量写入使用会话令牌命名的文件中。例如，以下文件：
/var/lib/php5/sess_9ceed0645151b31a494f4e52dabd0ed7
可能包含下列内容，其中包含用户配置的昵称：
攻击者可以对这种行为加以利用。首先，他将自己的昵称设置为<?php passthru(id);?>，如图17-3所示。然后，他包含会话文件，使用以下URL执行id命令，如图17-4所示。
图17-3 配置包含服务器可执行的脚本代码的昵称
图17-4 通过本地文件包含功能执行包含恶意昵称的会话文件
（1）对于在应用程序中已确定的任何漏洞，应发挥想象，考虑如何利用这个漏洞实现渗透测试目标，这是贯穿全书的主题。无数针对Web应用程序实施的成功攻击，最初都是从利用一个内部影响有限的漏洞开始的。通过利用信任关系并破坏应用程序其他地方实施的控制，渗透测试员就有可能利用一个看似细微的缺陷，实施严重的攻击。
（2）如果能在任何应用程序组件上执行任意命令，并能够与其他主机建立网络连接，应考虑向网络与操作系统层面中的应用程序其他基础架构发动直接攻击，以扩大攻击范围。
如果以严谨的方式执行多层架构，该架构就可以显著提高应用程序的安全，因为它能够将一次成功攻击的影响控制在局部。在前面描述的基本LAMP配置中，所有组件都在一台计算机上运行，攻破其中一个层就可能导致整个应用程序被完全攻破。在更安全的架构中，攻击者攻破一个层，只能部分控制应用程序的数据与处理操作，因而其造成的影响有限，可能仅局限于被攻破的层中。
每个层应尽可能实施自己的控制，防止未授权操作；并不得信任其他应用程序组件，以阻止该层可能有助于防御的安全违反。以下是将这个原则应用于不同应用程序层的一些实例。
应用程序服务器层应对特殊的资源与 URL 路径实施基于角色的访问控制。例如，应用程序服务器应核实所有访问/admin路径的请求均由管理用户提出，也可以对各种资源（如特殊类型的脚本与静态资源）实施访问控制。这样做可以减轻Web应用程序层存在的某些访问控制缺陷造成的影响，因为如果用户无权访问某些功能，那么他们提出的请求在到达这个层之前就已经被阻止。
数据库服务器层可以为应用程序的不同用户和操作提供各种权限的账户。例如，可以给未通过验证的用户分配一个只读访问权限的低权限账户，且该账户只能访问一部分数据。至于已通过验证的不同类型的用户，可以向他们分配各种数据库账户，并根据用户的角色，允许其读取和写入不同的应用程序数据。这样做可以减轻许多SQL注入漏洞造成的影响，因为即使攻击取得成功，攻击者也只能访问用户合法使用应用程序时所能获得的数据。
所有应用程序组件可以使用拥有正常操作所需的最低权限的操作系统账户运行。这样做可以减轻这些组件中存在的任何命令注入或文件访问漏洞造成的影响。在设计合理并得到充分强化的架构中，攻击者就无法利用这种漏洞访问敏感数据或执行未授权操作。
应尽可能地将每个层隔离开来，避免它们在无意间彼此交互。为实现这个目标，有些时候可能需要在不同的主机上运行不同的组件。以下是应用这个原则的一些实例。
一个层不得读取或写入其他层使用的文件。例如，应用程序层不得访问任何用于保存数据库数据的物理文件，它只能通过一个适当权限的用户账户，以指定的方式使用数据库查询访问这些数据。
对不同基础架构组件之间的网络级访问进行过滤，仅允许需要与不同应用程序层彼此通信的服务。例如，执行应用程序主要逻辑的服务器只能通过用于进行 SQL 查询的端口与数据库服务器交互。这种防范并不能阻止利用这种服务针对数据库层的攻击，但它能够阻止以数据库服务器为对象的基础架构攻击，并且能够防止攻破操作系统的攻击者到达组织的内部网络。
根据架构所使用的技术，我们可以在架构的不同组件内实施各种保护措施，以达到将某个成功攻击的影响限制在局部的目的。以下是实施这些控制的一些实例。
应根据配置与漏洞补丁，把每台主机上的技术栈的各个层面进行安全强化。如果服务器的操作系统存在缺陷，那么拥有低权限账户的攻击者就可以利用一个命令注入漏洞提升自己的权限，从而完全控制整个服务器。如果其他主机没有得到强化，这种攻击就可能会在整个网络中扩散。另一方面，如果基础服务器安全可靠，攻击造成的影响会被完全局限在一个或几个应用程序层中。
应对保存在任何应用程序层中的数据进行加密，以防止攻破该层的攻击者轻松获得这些数据。用户证书和其他敏感信息（如信用卡号），应以加密形式保存在数据库中。如有可能，应使用内置保护机制保护保存在Web应用程序层中的数据库证书。例如，在ASP.NET 2.0中，加密的数据库连接字符串可保存在web.config 文件中。
许多组织通过外部提供商向公众提供他们的Web应用程序。这些服务包括组织通过其访问Web与数据库服务器的简单主机服务，以及代表组织主动维护应用程序的成熟应用程序服务提供商（Application Service Provider，ASP）。缺乏能力与资源部署自己的应用程序的小型企业常常采用这种服务，但一些知名公司有时也使用这些服务来部署特殊的应用程序。
大多数Web与应用程序主机服务提供商拥有众多客户，且常常使用相同的基础架构或者紧密相连的基础架构支持许多客户的应用程序。因此，选择使用其中一种服务的组织必须考虑以下相关威胁。
服务提供商的一名恶意客户可能试图破坏该组织的应用程序及其数据。
一名不知情的客户可能部署一个易受攻击的应用程序，使得恶意客户能够攻破共享的基础架构，从而攻击组织的应用程序及其数据。
在共享系统中运行的Web站点是企图丑化尽可能多的Web站点的“脚本小子”的主要攻击目标，因为只要攻破一台共享主机，他们就能在短期内向数百台明显自治的Web站点实施攻击。
简单的共享主机配置中，一台Web服务器只需要支持几个域名各不相同的虚拟Web站点。它通过Host消息头达到这个目的，在HTTP 1.1中，请求中必须包含该消息头。当浏览器提出一个HTTP请求时，请求中即包含一个Host消息头，该消息头中含有相关URL中的域名；然后，请求被传送到与域名关联的 IP 地址中。如果解析几个域名得到相同的IP地址，在这个地址上的服务器仍然能够确定请求希望访问哪一个Web站点。例如，可以配置Apache使用以下配置支持几个Web站点，这个配置为每个虚拟主机站点设定各不相同的Web根目录。
许多ASP提供现成的应用程序，可由客户修改与定制后使用。对于拥有大量业务、需要部署功能强大复杂、能为终端用户提供基本相同功能的应用程序的行业，使用这种模型可以节省大量成本。使用ASP提供的这种服务，商家可迅速获得一个知名品牌的应用程序，而且不必投入大量的安装与维护成本。
在金融服务行业，ASP 应用程序市场特别成熟。举例来说，在某个国家，可能有数千家小型零售商希望向顾客提供店内支付卡与信贷服务。这些零售商将这项服务外包给若干不同的信用卡提供商，其中许多提供商为新创办的企业，而非历史悠久的知名银行。这些信用卡提供商提供一种商品化服务，而成本是其中一个关键的竞争因素。因此，许多提供商使用一家ASP为终端用户提供Web应用程序。因此，每一家ASP都对相同的应用程序进行定制处理，以满足大量不同零售商的需求。
图17-5说明了这种服务的典型组织结构与责任划分。从不同代理商与相关任务的角度看，这种服务存在与共享主机基本模型相同的安全问题，但这些问题可能更复杂。而且，这种服务还存在其他特殊的问题，如17.2.3节所述。
图17-5 一家典型应用程序服务提供商的组织结构
共享主机与ASP环境引入一系列新的潜在漏洞，攻击者可利用它们针对共享基础架构中的一个或几个应用程序进行攻击。
因为各种外部组织需要更新与定制共享环境中的不同应用程序，提供商必须执行实现这种远程访问的机制。在最简单的虚拟主机Web站点中，FTP或SCP之类的上传工具即可达到这种目的，客户通过它们在自己的Web根目录中写入文件。
如果主机服务提供一个数据库，客户可能需要直接访问数据库，以配置数据库设置，获取应用程序保存的数据。这时，提供商可执行一个实现某些数据库管理功能的接口，或者通过因特网提供数据库服务，允许客户直接建立连接，并使用他们自己的工具。
在成熟的ASP环境中，各种类型的客户需要对共享应用程序的组件进行不同程度的定制，这时，提供商通常会运行功能强大的应用程序，帮助客户完成这些任务。通常，通过一个VPN（Virtual Private Network，虚拟专用网络）或一个连接ASP基础架构的专用连接，就可以访问这些应用程序。
根据远程访问机制所涵盖的范围，攻击者可针对共享环境实施各种不同的攻击。
远程访问机制本身并不安全。例如，FTP协议未加密，使得处在适当位置（例如，在客户自己的 ISP 内）的攻击者能够截获登录证书。访问机制中还可能包含未打补丁的软件漏洞或配置缺陷，使得匿名攻击者能够避开访问机制，破坏客户的应用程序和数据。
远程访问机制许可的访问可能过于宽泛，或者未能对客户进行适当的隔离。例如，当用户只需要文件访问时，访问机制可能会为用户提供一个命令shell。另外，访问机制可能并没有限制客户只能访问自己的目录；相反，却允许他们更新其他客户的内容，或者访问服务器操作系统中的敏感文件。
在文件系统访问方面，同样的注意事项也适用于数据库。访问机制可能没有对数据库进行适当的隔离，为每名客户提供不同权限的账户。直接数据库连接可能使用标准ODBC之类的非加密渠道来实现。
如果部署一个定制应用程序实现远程访问（例如，通过一家ASP），这个应用程序必须负责控制不同客户对共享应用程序的访问。管理应用程序中存在的任何漏洞都可能会导致恶意客户，甚至是匿名用户破坏其他客户的应用程序，还会使拥有有限权限的客户能够更新应用程序的皮肤，从而提升其权限，或者修改应用程序核心功能组件，以实现他们的目的。如果部署了这种类型的管理应用程序，那么该应用程序中存在的任何漏洞都可能会导致针对终端用户访问的共享应用程序的攻击。
在一个共享主机环境中，不同的客户通常需要向服务器合法上传并执行任意脚本。这会导致单主机应用程序中并不存在的问题。
在最明显的攻击中，恶意客户可能会上传攻击服务器自身或其他客户应用程序的内容。例如，下面的 Perl 脚本在服务器上运行一个远程命令工具：
从因特网上访问以下这段脚本，客户就能够在服务器上执行任意操作系统命令：
由于恶意客户的命令以Apache用户的身份执行，这很可能使得该客户能够访问属于共享主机服务其他客户的脚本和数据。
ASP 管理的共享应用程序中也存在这种威胁。虽然核心应用程序功能由ASP控制并更新，但个体用户还是能够以某种确定的方式修改这项功能。恶意客户可以在他们控制的代码中引入其他人难以察觉的后门，从而攻破共享应用程序，访问其他客户的数据。
提示 后门脚本可以用大多数Web脚本语言创建。欲知更多以其他语言编写的脚本实例，请访问：http://net-square.com/ papers/one_way/one_way.html#4.0。
即使共享环境中的所有客户全都并无恶意，且仅上传经过环境所有者确认的合法脚本，但如果个别用户对存在于应用程序中的漏洞并不知情，应用程序之间的攻击仍有可能发生。在这种情况下，恶意用户可以利用某个应用程序中的漏洞攻破该应用程序以及共享环境中的所有其他应用程序。许多常见的漏洞都属于这种类型，如下所示。
攻击者可以利用某个应用程序中的SQL注入漏洞在共享数据库中执行任意 SQL 查询。如果没有完全隔离访问数据库的不同客户，攻击者就可以读取并修改所有应用程序使用的数据。
攻击者可以利用某个应用程序中的路径遍历漏洞读取或写入服务器文件系统中的任意文件，包括那些属于其他应用程序的文件。
攻击者可以采用与前面描述的恶意客户使用的方法类似的方法，利用某个应用程序中的命令注入漏洞攻破服务器以及服务器上运行的其他应用程序。
前面描述的各种攻击全部可能会在共享ASP应用程序中发生。由于客户可以按照自己的需求对核心应用程序功能进行定制，因此定制应用程序的用户可以利用某名客户引入的漏洞攻击主共享应用程序，从而窃取所有ASP客户的数据。
除这些攻击以外，由于共享应用程序的各种组件必须彼此交互，因而恶意客户或用户能够攻破其他共享的应用程序，如下所示。
由不同应用程序生成的数据通常被分配到一个公共的位置，可以被共享应用程序中拥有较高权限的ASP级用户查看。这意味着攻击者可以利用定制应用程序中存在的XSS漏洞攻破共享应用程序。例如，如果攻击者能够在日志文件条目、支付记录或者个人联系信息中注入JavaScript代码，他们就可以劫持一名ASP级用户的会话，从而访问敏感的管理功能。
ASP通常使用一个共享数据库保存所有客户的数据。应用程序与数据库层面是否对数据访问实施了严格的隔离，这一点无法确定。但是，无论是哪一种情况，都会存在一些共享组件，如数据库存储过程，它们负责处理属于多名客户的数据。恶意客户或用户可以利用这些组件中存在的有缺陷的信任关系或漏洞访问其他应用程序中的数据。例如，一个定义者权限共享存储过程中的SQL注入漏洞可能会导致整个共享数据库被攻破。
（1）检查为共享环境中的客户提供的、便于他们更新和管理内容与功能的访问机制。考虑以下问题。
远程访问机制是否使用一个安全的协议与经过适当强化的基础架构？
客户是否能够访问他们正常情况下不能访问的文件、数据及其他资源？
客户是否能够在主机环境中获得一个交互式的shell，并执行任意命令？
（2）如果使用一个所有权应用程序，以方便客户配置和定制共享环境，考虑是否能够以这个应用程序为攻击目标，攻破该环境本身及其中运行的所有应用程序。
（3）如果能够在某个应用程序中执行命令、注入SQL脚本或访问任意文件，仔细研究，看是否能够以此扩大攻击范围，攻破其他应用程序。
（4）如果渗透测试员正在攻击一个使用ASP主机的应用程序，且该应用程序由许多共享与定制组件构成，确定其中的任何共享组件，如日志机制、管理功能以及数据库代码组件，尝试利用这些组件攻破应用程序的共享部分，进而攻破其他应用程序。
（5）如果所有共享环境使用一个常用的数据库，使用NGSSquirrel之类的数据库扫描工具，对数据库配置、补丁级别、表结构以及许可进行全面审查。数据库安全模型中存在的任何缺陷都可以被加以利用，将攻击范围由一个应用程序扩大到另一个应用程序。
基本上，热门词汇“云”是指越来越多地将应用程序、服务器、数据库和硬件外包给外部服务提供商。此外，它也指目前共享托管环境的高度虚拟化。
从广义上讲，云服务是指提供API、应用程序或用于客户交互的Web界面的基于因特网的按需服务。通常，云计算提供商会存储用户数据或处理业务逻辑来提供相关服务。从终端用户的角度看，传统的桌面应用程序将升级为基于云的应用程序，各种企业可能会用按需服务来替代所有服务器。
在迁移到云服务的过程中，缺乏控制是一个经常被提及的安全问题。与传统的服务器或桌面软件不同，用户没有办法提前评估特定云服务的安全性，而需要将管理服务和数据的所有责任交给第三方。对企业而言，他们需要将更多控制托付给某个环境，而该环境包含的风险却无法完全定性或量化。由于基于Web的平台并不像传统的客户端/服务器可下载的产品那样经过严格的测试，因此，在支持云服务的Web应用程序中发现的漏洞也往往不为人们所了解。
这种对缺乏控制的担心，与当前企业在选择托管服务提供商、或用户在选择Web邮件服务商时的担忧类似。但是，仅仅这种担忧并不能反映云计算带来的日益严重的安全风险。攻破一个传统的Web应用程序可能会影响到成千上万名个体用户，但攻破云服务却可能影响到成千上万名云订阅用户及其用户群体。虽然存在缺陷的访问控制会使攻击者能够未授权访问工作流程应用程序中的敏感文档，但在云自助服务应用程序中，这种缺陷可能会导致攻击者能够未授权访问服务器或服务器集群。利用管理后端门户云服务中的同一漏洞，攻击者甚至能够访问整个企业基础架构。
由于定义不明确，每个云服务提供商的实施方式各不相同，因此并没有适用于所有云体系架构的漏洞列表。但是，我们仍然可以确定一些专门针对云计算体系架构的主要漏洞区域。
注解 关于云安全，人们经常提到的一种防御机制是静态或动态数据加密。但是，在这种情况下，加密只能提供最低限度的保护。如17.1节所述，如果攻击者避开应用程序的身份验证或授权检查，针对数据提出看似合法的请求，栈中的组件就会自动调用任何解密功能。
在使用熵生成随机数字时，许多应用程序依赖操作系统的功能来执行这一操作。常用的熵源大多与系统本身的功能有关，如系统正常运行时间，或有关系统硬件的信息。如果系统被克隆，拥有其中一个克隆系统的攻击者就可以确定用于生成随机数字的熵源，这些信息又可用于更准确地预测随机数字发生器的状态。
用于配置和监视服务器的界面是企业云计算服务的核心应用。对用户而言，该界面是一个自助环境，通常是最初用于内部服务器管理的工具的Web版本。以前连接到网络的独立工具往往缺乏可靠的会话管理和访问控制机制，在没有预先采用基于角色的隔离的情况下更是如此。笔者曾发现一些将令牌或GUID用于服务器访问的情况。在其他情况下，应用程序仅仅通过序列化接口来调用任何管理方法。
和大多数新技术一样，云服务提供商采用功能优先的方法来吸引新用户。从企业的角度来看，云环境几乎总是通过自助Web应用程序管理。用户获得一系列用户友好的方法，并通过这些方法来访问数据。云服务通常并不提供功能“退出”机制。
用户需要定期调用大量云资源，为此，用户需要在客户端上存储一个永久身份验证令牌，以免输入密码，并用于标识设备（相对于用户）。如果攻击者能够访问该令牌，就可以借此访问用户的云资源。
Web存储是云计算吸引终端用户的优势之一。为发挥效率，Web存储必须支持某种标准的浏览器或浏览器扩展、一系列技术和HTTP扩展（如WebDAV），并且通常需要支持存入缓存或基于令牌的证书（如上所述）。
此外，域上的Web服务器通常可以通过因特网访问。如果某个用户可以上传HTML文件并诱使其他用户访问其上传的文件，他就可以攻破这些使用同一服务的用户。与此类似，攻击者可以利用Java同源策略并上传一个JAR文件，从而在该文件被因特网上的其他位置调用时实现完全的双向交互。
由于使用相同工具的客户可能怀有恶意企图，以及不知情的客户可能无意中在环境中引入漏洞，因此，共享环境给应用程序安全带来了新的威胁。为解决这种双重威胁，设计共享环境时必须仔细处理客户访问、隔离与信任关系，并实施并不直接适用于单主机应用程序的控制。
无论向客户提供何种机制来帮助他们维护自己控制的内容，都应防止这种机制被第三方和恶意客户未授权访问。
远程访问机制应实施严格的身份确认，使用难以窃听的加密技术，并进行充分的安全强化。
仅准予个体用户最低的访问权限。例如，如果一名客户需要向一台虚拟主机服务器上传脚本，就应仅向他分配读取与写入他自己的文档根目录的访问权限。如果需要访问一个共享数据库，就应使用一个无法访问属于其他客户的数据或其他组件的低权限账户进行访问。
如果使用一个定制的应用程序提供客户访问，该应用程序必须满足严格的安全需求，并根据它在保护共享环境安全中发挥的作用进行测试。
不能信任共享环境中的客户，认为他们仅建立没有漏洞的无害功能。因此，稳定可靠的解决方案是应使用本章前半部分描述的架构控制来保护共享环境及其客户，避免受到通过不当内容实施的攻击。这要求隔离给予每名客户的功能，确保将任何有意或无意攻击的影响限制在局部，使其不会伤害其他客户。
每名客户的应用程序应使用一个独立的操作系统账户访问文件系统，该账户仅拥有读取与写入应用程序文件路径的权限。
强大系统功能与命令的访问权限应仅限于操作系统等级，且应只分配所需的最低权限。
应在任何共享数据库中实施相同的保护措施。应为每名客户使用一个单独的数据库实例，仅向客户分配低权限的账户，只允许他们访问自己的数据。
注解 许多基于LAMP模型的共享主机环境依靠PHP安全模式来限制某个恶意或易受攻击脚本的潜在影响。这种模式防止PHP脚本访问某些强大的PHP函数，将对其他函数的操作实施限制（请参阅第19章了解相关内容）。然而，这些限制并非完全有效，而且非常容易避开。虽然安全模式能够提供有用的防御，但由于它需要操作系统信任应用程序层，以控制它的操作，因此，从架构上讲，在这里控制恶意或易受攻击的应用程序造成的影响并不合适。由于这个及其他原因，PHP 6以后的版本删除了安全模式。
提示 如果能够在服务器上执行任意PHP命令，可使用phpinfo()命令返回PHP环境的配置信息。可以检查这些信息，了解PHP是否激活安全模式，以及其他配置选项如何影响执行的操作。请参阅第19章了解更多详情。
在ASP环境中，应用程序包含各种共享与定制的组件，这时应在各方控制的组件之间实施信任边界。如果一个数据库存储过程之类的共享组件接收从某一名客户的定制组件发出的数据，那么就不应信任这些数据，就好像它们是由终端用户送出的一样。每个组件都应对它的信任边界以外的相邻组件进行严格的安全测试，确定其中存在的、攻击者可以利用易受攻击的组件或恶意组件攻破其他应用程序的漏洞。应特别注意共享日志与管理功能。
Web应用程序架构中实施的安全控制可帮助应用程序所有者显著改善他们部署的应用程序的安全状态。但是，如果应用程序架构中存在缺陷与疏忽，攻击者就可以利用它们进一步扩大攻击范围，通过一个组件攻击另一个组件，最终攻破整个应用程序。
另一方面，共享主机与基于ASP的环境也引发了一系列新的、难以解决的安全问题，包括单主机应用程序中并不存在的信任边界。如果攻击者想要攻击共享环境中的一个应用程序，他就应该集中精力对共享环境实施攻击，确定是否可以通过其中的某个应用程序攻破这个环境，或者利用一个易受攻击的应用程序攻击其他应用程序。
欲知问题答案，请访问http://mdsec. net/wahh。
（1）假设受攻击的应用程序使用两台不同的服务器：一台应用程序服务器和一台数据库服务器。已经发现一个漏洞，可以在应用程序服务器上执行任意操作系统命令。是否可以利用这个漏洞获取保存在数据库中的敏感应用程序数据？
（2）在另外一种情形中发现了一个SQL注入漏洞，可以利用它在数据库服务器上执行任意操作系统命令。是否可以利用这个漏洞攻破应用程序服务器？例如，是否可以修改保存在应用程序服务器中的应用程序脚本以及向用户返回的内容？
（3）在攻击共享环境中的一个Web应用程序时，与ISP签订合约后，在所针对的同一台服务器上获得了一些Web空间，可以向其中上传PHP脚本。
是否可以利用这种情况攻破目标应用程序？
（4）Linux、Apache、MySQL与PHP等架构组件常安装在同一台物理服务器上。为何这样做会削弱应用程序架构的安全状况？
（5）如何找到证据来证明所攻击的应用程序由某个应用程序服务提供商托管？
Copyright ©2010-2022 比特日记 All Rights Reserved.