与任何其他应用程序一样，Web应用程序也依赖于支持它的其他技术栈（technology stack），包括Web服务器、操作系统与网络基础架构。这些组件中的任何一个都可能成为攻击者的目标，应用程序依赖的技术往往可使攻击者能够完全攻破整个应用程序。
本书主要讨论渗透测试员如何攻击Web应用程序，因此大多数上述类型的攻击不在本书的讨论范围之内，但针对Web服务器层的攻击以及相关应用程序层的防御是个例外。内联防御通常用于保障Web应用程序的安全及识别攻击。避开这些防御是攻破应用程序的关键步骤。
迄今为止，我们并未对Web服务器与应用程序服务器进行区分，因为各种攻击主要针对的是应用程序的功能，无论应用程序以何种方式提供这些功能。实际上，大部分表示层、与后端组件的通信，以及核心安全框架都可能由应用程序容器管理。这就进一步扩大了攻击范围。很明显，如果实现这些框架的技术存在任何漏洞，可用于直接攻破应用程序，这些漏洞将会引起攻击者的关注。
本章主要讨论如何利用Web服务器中存在的漏洞攻击其上运行的Web应用程序。当攻击Web服务器时，渗透测试员可以利用的漏洞分为两大类：服务器配置缺陷和应用程序服务器软件中的安全漏洞。相关漏洞的列表可能并不全面，因为这类软件总是在不断变化，但本章介绍的漏洞将说明各种应用程序在执行自己的本地扩展、模块或API，或访问外部功能时可能遇到的常见危险。
在本章中，我们还将分析Web应用程序防火墙，介绍其优缺点，并详细说明如何突破这些防火墙以实施攻击的常用方法。
即使最简单的Web服务器也带有大量控制其行为的配置选项。以前发布的许多服务器含有不安全的默认选项，如果不对它们进行强化，可能会使攻击者有机可乘。
许多Web服务器包含可被公众访问的管理接口。这些接口可能位于Web根目录的某个特定位置，或者在8080或8443端口上运行。通常，管理接口使用众所周知的默认证书，这些证书在安装时不需要进行修改。
一些最常见的管理接口的默认证书如表18-1所示。
表18-1 一些常见管理接口的默认证书
用 户 名 密 码
Apache Tomcat admin （无）
tomcat tomcat
root root
Sun JavaServer admin admin
Netscape Enterprise Server admin admin
Compaq Insight Manager administrator administrator
anonymous （无）
user user
operator operator
user public
Zeus admin （无）
除Web服务器上的管理接口外，大量设备（如交换机、打印机与无线接入点）还使用禁止修改其默认证书的Web接口。以下资源列出了大量技术的默认证书：
www.cirt.net/passwords
www.phenoelit-us.org/dpl/dpl.html
（1）检查应用程序解析过程中得到的结果，确定应用程序使用的、可能包含可访问的管理接口的Web服务器与其他技术。
（2）对Web服务器进行端口扫描，确定在指向主目标应用程序的不同端口上运行的所有管理接口。
（3）对于确定的接口，查阅制造商文档资料与常用密码表，获得默认证书。使用Metasploit的内置数据库扫描服务器。
（4）如果默认证书无效，使用第6章描述的技巧尝试猜测有效的证书。
（5）如果能够访问一个管理接口，审查可用的功能，确定是否可以利用这项功能进一步攻破主机与主应用程序。
大多数Web服务器中含有可用于攻击服务器自身或主目标应用程序的默认内容与功能。以下是一些可能有用的默认内容。
为管理员设计的调试与测试功能。
用于演示某些常见任务的样本功能。
本应禁止公众访问，但无意中允许公众访问的强大功能。
包含仅在安装时有用的信息的Web服务器手册。
通常，为方便管理员进行诊断而设计的功能对攻击者极其有用，因为其中包含与服务器和它上面运行的应用程序的配置及与运行状态有关的重要信息。
图18-1为默认页面phpinfo.php，许多Apache版本中都含有该页面。这个页面运行PHP函数phpinfo()并返回其结果。页面中包含大量与PHP环境、配置设置、Web服务器模块和文件路径有关的信息。
图18-1 默认页面phpinfo.php
许多服务器默认包含各种样本脚本与页面，其目的在于演示某些Web服务器功能与API的用法。通常，这些样本功能并无害处，也不会给攻击者提供攻击的机会。但实际上，基于以下两点原因，事实并非如此。
许多样本脚本包含安全漏洞，可被攻击者用于执行脚本作者不希望执行的操作。
许多样本脚本甚至执行可被攻击者直接利用的功能。
第一个问题的示例为Jetty版本7.0.0中包含的Dump Servlet。此Servlet可以通过/test/jsp/dump.jsp之类的URL访问。一旦被访问，它会打印Jetty安装及当前请求的各种详情，包括请求查询字符串。因此，攻击者只需在URL中包含脚本标签，如/test/jsp/dump.jsp?%3Cscript%3Ealert(%22xss%22)%3C/script%3E，即可实施跨站点脚本攻击。
Apache Tomcat中的Sessions Example脚本是第二个问题的典型示例。如图18-2所示，这个脚本可用于获取并设置任意会话变量。如果在服务器上运行的应用程序将敏感数据保存在用户会话中，攻击者就可以查看这些数据，将通过修改它的值来破坏应用程序的处理过程。
图18-2 Apache Tomcat中的默认SessionsExample脚本
许多Web服务器软件包含一些公众无法访问的强大功能，但终端用户通过某种方式可以访问这些功能。许多时候，只要提供正确的管理证书，应用程序服务器都允许通过应用程序本身使用的同一HTTP端口来部署Web档案（WAR文件）。应用程序的这种部署过程是黑客的主要攻击目标。常见的渗透测试框架能够自动完成以下过程：扫描默认证书、上传包含后门的Web档案，然后执行该档案以获取远程系统上的命令外壳，如图18-3所示。
图18-3 使用Metasploit攻破重要的Tomcat服务器
JBoss默认安装的JMX控制台是一种典型的强大默认内容。JMX控制台被描述为“JBoss应用程序服务器微内核的原始视图”。实际上，通过它可以直接访问JBoss应用程序服务器中的任何托管Bean。由于可用功能的数量众多，因此，人们从中发现了大量安全漏洞。其中，最简单的利用方法，是使用DeploymentFileRepository中的store方法创建包含后门的WAR文件，如图18-4所示。
图18-4 JMX控制台包含可用于部署任意WAR文件的功能
例如，以下URL将上传一个包含后门的cmdshell.jsp页面：
如图18-5所示，该URL将成功创建可执行以下代码的服务器端后门：
图18-5 使用JMX控制台在JBoss服务器上部署后门WAR文件的成功攻击
然后，内置的部署扫描器会自动将木马WAR文件部署到JBoss应用程序服务器中。部署该文件后，即可以在新建的cmdshell应用程序中访问这个文件，在本示例中，其中仅包含cmdshell.jsp：
注解 要解决上述问题，需要将GET和POST方法仅限于管理员使用。但是，只需使用HEAD方法提出上述请求，即可轻松突破这种限制（ 有关详细信息，请访问www.securityfocus.com/bid/39710/）。和任何基于配置的漏洞一样，Metasploit等工具能够相当高效地利用各种此类JMX漏洞。
强大的默认功能的最典型示例，要属Oracle应用程序服务器实施的PL/SQL网关；其他Oracle产品，如电子商务套件（E-Business Suite）也采用了这个网关。这项功能提供一个接口，通过它可向一个后端Oracle数据库提出Web请求。攻击者可以使用类似于下面的URL向数据库过程提交任意参数：
这项功能本用于将某个数据库执行的业务逻辑转换成用户友好的Web应用程序。但是，由于攻击者能够指定任意过程，因此，他可以利用PL/SQL网关访问数据库中的强大功能。例如，SYS.OWA_UTIL.CELLSPRINT过程可用于执行任意数据库查询，从而获取敏感数据：
为防止这种攻击，Oracle引入一个名为PL/SQL排除列表（Exclusion List）的过滤器。该过滤器检查被访问的包的名称，并阻止攻击者访问任何以下面的表达式开头的包：
该过滤器旨在阻止攻击者访问数据库中功能强大的默认功能。但是，上面的列表并不全面，无法阻止攻击者访问数据库管理员拥有的其他功能强大的默认过程，如CTXSYS与MDSYS。此外，本章后面还会介绍与PL/SQL排除列表有关的一些问题。
当然，PL/SQL网关最初主要用于传送数据包和过程，但此后发现它的许多默认功能都包含漏洞。2009年，电子商务套件的默认数据包组成部分被证实包含若干漏洞，包括可被攻击者用于编辑任意页面。研究人员提供了使用icx_define_pages.DispPageDialog在管理员的登录页面中注入HTML，以实施保存型跨站点脚本攻击的示例：
（1）Nikto之类的工具可有效确定大多数默认的Web内容。第4章描述的应用程序解析过程应已确定所针对的服务器中的绝大多数默认内容。
（2）使用搜索引擎和其他资源确定与已知应用程序使用的技术有关的默认内容与功能。如果可能，可在本地计算机上安装这些技术，从中查找任何可在渗透测试中利用的默认功能。
当Web应用程序收到一个访问目录而非真实文件的请求时，它会以下面这3种方式进行响应。
它返回目录中的一个默认资源，如index.html。
它返回一个错误，如HTTP状态码403，表示请求被禁止。
它返回一个列表，显示目录的内容，如图18-6所示。
图18-6 目录列表
许多时候，目录列表（directory listing）并不会造成安全威胁。例如，泄露一个图像目录的索引根本不会引起任何不良后果。确实，人们常常有意泄露目录列表，因为它们有助于在包含静态内容的站点间导航，如前例所示。但是，基于以下两个主要原因，获得目录列表有利于攻击者对应用程序实施攻击。
许多应用程序并不对它们的功能与资源实施正确的访问控制，而是依赖于攻击者忽略用于访问敏感内容的URL（请参阅第8章了解相关内容）。
日志、备份文件、旧版脚本等文件与目录经常被无意遗漏在服务器的Web根目录中。
在上述两种情况下，真正的漏洞位于其他地方，其原因在于没有对敏感数据实施正确的访问控制。但是，由于这些漏洞极其普遍，不安全的资源的名称可能很难猜测，因此，这时获得目录列表对攻击者而言非常重要，往往可以让他们迅速攻破整个应用程序。
向在应用程序解析过程中发现的Web服务器上的每一个目录提出一个请求，确定任何返回目录列表的场合。
注解 除上述可直接获得目录列表的情况外，攻击者还可以利用大量已经在Web服务器中发现的漏洞获取目录列表。本章后面将讨论其中一些漏洞。
WebDAV指用于Web分布式创作与版本控制的HTTP方法集合。自1996年以来，这些方法得到了广泛应用。最近的云存储和协作应用程序也采用了WebDAV方法，因为这些应用程序需要使用现有的防火墙友好的协议（如HTTP）跨系统访问用户数据。如第3章所述，HTTP请求能够使用除标准GET和POST以外的各种方法。WebDAV添加了大量其他可用于操纵Web服务器上的文件的方法。鉴于其提供的功能的特点，如果这些方法可以由低权限用户访问，这些用户就可以利用它们对应用程序实施有效攻击。以下是一些值得注意的方法：
PUT，向指定位置上传附加文件；
DELETE，删除指定的资源；
COPY，将指定的资源复制到Destination消息头指定的位置；
MOVE，将指定的资源移动到Destination消息头指定的位置；
SEARCH，在目录路径中搜索资源；
PROPFIND，获取与指定资源有关的信息，如作者、大小与内容类型。
可以使用OPTIONS方法列出某个特定目录允许的HTTP方法。例如：
这个响应指出，上面列出的几个强大的方法可以在目录中使用。然而，实际上，使用这些方法需要通过身份验证，或取决于其他限制。
其中，PUT方法特别危险。如果能够上传Web根目录中的任意文件，就可以在服务器上创建将由服务器端模块执行的后门脚本，从而完全控制应用程序，甚至是Web服务器本身。如果PUT方法存在且被激活，就可以通过以下方式证实这一点：
注意，应用程序可能会针对每个目录实施不同的权限，因此，在测试过程中需要进行递归检查。这时，可以使用DAVTest（将在下一节介绍）之类的工具在服务器的所有目录中检查PUT方法，并确定这些目录允许使用哪些文件扩展名。为克服使用PUT上传后门脚本的限制，该工具还会在MOVE方法后使用PUT方法，例如：
http://mdsec.net/public/
提示 允许终端用户上传文件的WebDAV实例通常禁止上传特定于服务器环境的服务器端脚本语言扩展。更常见的情况是，用户可以上传HTML或JAR文件，攻击者可以利用这两种文件实施针对其他用户的攻击（请参阅第12章和第13章了解相关信息）。
要测试服务器如何处理不同的HTTP方法，需要使用某种工具，如Burp Repeater，渗透测试员可以使用该工具发送任意请求，并完全控制消息头和消息主体。
（1）使用OPTIONS方法列出服务器使用的HTTP方法。注意，不同目录中激活的方法可能各不相同。
（2）许多时候，一些方法被告知有效，但实际上它们并不能使用。有时，即使OPTIONS请求返回的响应中没有列出某个方法，但该方法仍然可用。因此，应手动测试每一个方法，确认其是否可用。
（3）如果发现一些WebDAV方法被激活，应使用激活WebDAV的客户端进行深入调查，如Microsoft FrontPage或Internet Explorer中的“以Web文件夹方式打开”（Open as Web Folder）选项。
（a）尝试使用PUT方法上传一个良性文件，如文本文件。
（b）如果上传成功，尝试使用PUT上传一个后门脚本。
（c）如果运行脚本所需的扩展名受到阻止，尝试以.txt扩展名上传该文件，并使用MOVE方法将其移动到采用新扩展名的文件中。
（d）如果以上方法均无效，尝试上传一个JAR文件，或一个浏览器会将其内容显示为HTML的文件。
（e）使用davtest.pl之类的工具遍历所有目录。
Web服务器有时被配置为转发或反向HTTP代理服务器（请参阅第3章了解相关内容）。如果一台服务器被配置为转发代理服务器，那么根据它的配置，可以利用该服务器执行以下各种攻击。
攻击者可以使用该服务器攻击因特网上的第三方系统，对攻击目标而言，恶意流量似乎是来自易受攻击的代理服务器。
攻击者可以使用代理服务器连接组织内部网络中的任意主机，攻击从因特网无法直接访问的目标。
攻击者可以使用代理服务器反向连接代理服务器主机上运行的其他服务，突破防火墙限制，并利用信任关系避开身份验证。
可以使用两种主要的技巧让转发代理服务器进行正向连接（onward connection）。第一种方法是，发送一个包含完整URL的HTTP请求，该URL中包括一个主机名称与一个端口号（可选）。例如：
如果配置服务器将请求转发到指定的主机，那么它将返回那台主机的内容。但是，一定记得核实返回的内容不是来自最初的服务器。大多数Web服务器接受包含完整URL的请求；许多服务器则完全忽略在URL中指定的主机，从它们自己的Web根目录中返回被请求的资源。
第二种利用代理服务器的方法是使用CONNECT方法指定到目标主机与端口号。例如：
如果服务器以这种方式做出响应，就表示它正在代理该连接。通常，第二种技巧的功能更强大，因为现在代理服务器将转发传送到指定主机以及由该主机送出的所有流量，允许穿透连接中的其他协议，攻击非HTTP服务。然而，大多数代理服务器对通过CONNECT方法可到达的端口实施严格的限制，通常只允许连接端口443。
利用这种攻击的技巧已经在10.4.1节详细介绍过了。
（1）使用GET与CONNECT请求，尝试用Web服务器作为代理服务器，连接因特网上的其他服务器，并获取其中的内容。
（2）尝试使用前面描述的两种技巧连接主机基础架构中的不同IP地址与端口。
（3）尝试使用前面描述的两种技巧，在请求中指定127.0.0.1为目标主机，连接Web服务器上的常用端口号。
第17章介绍了如何使用HTTP Host消息头指定返回内容的Web站点，配置Web服务器为几个Web站点的主机。在Apache中，虚拟主机通过以下方式配置：
除DocumentRoot指令外，还可以使用虚拟主机容器为Web站点指定其他配置选项。这时，我们常犯的一个错误是忽略默认主机，导致任何安全配置仅适用于一台虚拟主机，而在访问默认主机时却可轻易避开。
（1）使用以下方式向根目录提交GET请求：
正确的Host消息头；
随意Host消息头；
Host消息头中的服务器IP地址；
无Host消息头。
（2）对这些请求的响应进行比较。常见的结果是，在Host消息头中使用一个IP地址可获得目录列表。还可以获得各种默认内容。
（3）如果观察到不同的行为，使用生成不同结果的Host消息头重复应用程序解析过程。一定要使用-vhost选项进行一次Nikto扫描，确定在最初的应用程序解析过程中忽略的任何默认内容。
从本质上讲，保障Web服务器配置的安全并不困难；通常，疏忽大意与缺乏安全意识是造成问题的主要原因。最重要的是必须充分了解所使用的软件的文档资料及有关的强化指南。
就需要解决的常见配置问题而言，确保包括以下所有领域。
如有可能，修改所有默认证书，包括用户名和密码。删除任何不必要的账户。
在Web根目录的相关路径上应用访问控制列表（Access Control List，ACL），或者对非标准端口设置防火墙，阻止公众访问管理接口。
删除所有实现商业目的并不完全需要的默认内容与功能。浏览Web目录中的内容，确定任何遗留的项目，使用Nikto工具进行重复检查。
如果需要保留任何默认功能，尽量对其进行强化，禁用不必要的选项与行为。
在所有Web目录中查找目录列表。如有可能，在一个控制整个服务器的配置中禁用目录列表。还可以确保每个目录包含服务器默认提供的index.html文件。
除应用程序常用的方法外（通常为GET与POST方法），禁用其他所有方法。
确保没有将Web服务器配置为代理服务器。如果确实需要这项功能，应尽量强化其配置，只允许它连接可合法访问的特定主机与端口。还可以执行网络层过滤，以此作为另一层防御，控制Web服务器向外发出的请求。
如果Web服务器支持虚拟主机，确保在默认主机上实施服务器采用的所有安全强化措施。执行前面描述的测试，证明确实实施了安全强化。
Web服务器软件的形式各异，包括仅用于显示静态页面的极其简单的轻量级软件，以及能够处理各种任务、提供除业务逻辑本身以外的所有功能的高度复杂的应用程序平台。就后者而言，人们大多认为这类框架是安全的。以前，Web服务器软件被一系列严重的安全漏洞所困扰，使得攻击者能够执行任意代码、窃取文件和提升权限。这些年来，主流Web服务器平台已变得日渐可靠。许多情况下，核心功能仍保持静态，甚至经过精简，因为供应商有意减少默认的受攻击面。但是，即使这些漏洞越来越少，其背后的原理仍然适用。在本书第1版中，我们提供了一些最有可能包含漏洞的服务器软件示例。自第1版出版以来，人们在各类软件（通常为并行技术或服务器产品）中均发现了新的漏洞。除一些小型个人Web服务器及其他次要目标外，这些新漏洞大多存在于以下软件之中：
IIS和Apache中的服务器端扩展。
从头开发的新型Web服务器，这类服务器主要用于支持特定的应用程序，或作为开发环境的一部分提供。它们可能较少受到现实世界中的黑客的关注，因而更可能存在上述问题。
多年以来，Web应用程序框架一直存在各种严重的缺陷。我们将介绍最近在某个框架中发现的一个常见缺陷，这个缺陷导致在该框架上运行的许多应用程序都易于受到攻击。
.NET填充提示
.NET中的“填充提示”（padding oracle）漏洞是近年来最为著名的漏洞。.NET对CBC分组密码使用PKCS #5填充，其操作方式如下。
分组密码基于固定的分组大小进行操作，在.NET中，这样的分组通常为8或16字节。.NET采用PKCS #5标准为每一个明文字符串添加填充字节，以确保生成的明文字符串长度可以被分组大小整除。这时，.NET不是使用任意值进行填充，选择用于填充的值是填充字节的数量。每个字符串都会被填充，如果初始字符串是分组大小的倍数，将填充整个分组。因此，如果分组大小为8，则必须使用1个0x01字节、2个0x02字节，或最多8个0x08字节的任意组合进行填充。然后，将第一条消息的明文与称为初始化向量（IV）的预设消息分组进行XOR运算。（回顾我们在第7章讨论的在密文中选择模式时遇到的问题。）如第7章所述，接下来，第二条消息将与第一条消息的密文进行XOR运算，从而开始循环分组链。
整个.NET加密过程如下。
（1）选择明文消息。
（2）使用所需的填充字符数作为填充字节值填充该消息。
（3）将第一个明文分组与初始化向量进行XOR运算。
（4）使用三重DES加密从第3步的XOR运算得到的值。
从这时开始，将循环执行以下步骤，以加密剩余的消息（这就是第7章介绍的密码块链（CBC）过程）。
（5）将第二个明文分组与加密后的前一个分组进行XOR运算。
（6）使用三重DES加密XOR运算得到的值。
在2010年9月之前，易受攻击的.NET版本包含一个看似无害的信息泄露漏洞。如果在消息中发现填充错误，应用程序会报告错误，向用户返回500 HTTP响应码。如下所述，组合利用PKCS#5填充算法和CBC的上述行为，攻击者可以攻破整个.NET安全机制。
请注意，为了发挥效用，所有明文字符串应包含至少一字节的填充信息。此外还要注意，看到的第一个密文分组为初始化向量；该向量的唯一用途，是与消息的第一个加密分组的明文值进行XOR运算。为实施攻击，攻击者将向应用程序提交一个仅包含前两个密文分组的字符串。这两个分组分别为IV及第一个密文分组。然后，攻击者提交一个仅包含数字零的IV，并通过逐步递增该IV的最后一个字节，提出一系列请求。该字节将与密文中的最后一个字节进行XOR运算，除非针对该字节生成的值为0x01，否则加密算法将抛出错误！（前面我们讲过，任何字符串的明文值必须以一个或多个填充值结尾。由于第一个密文分组中不存在任何其他填充值，因此最后一个值必定被加密为0x01。）
攻击者可以利用以下错误条件——最终他会得到这样的值：如果将该值与密文分组的最后一个字节进行XOR运算，结果为0x01。这时，将可以确定最后一个字节y的明文值，因为：
因此，我们也由此确定x的值。
以上过程同样适用于密文中的倒数第二个字节。这次，在已知y值的情况下，攻击者将选择x的值（该值的最后一个字节将解密为0x02）。然后，他对初始化向量中的倒数第二个字符执行以上递归过程，并收到500 Internal Server Error消息，直到倒数第二个解密的字节为0x02。这时，消息末尾存在两个0x02字节，这是有效的填充，因而不会返回任何错误。然后，可以对目标分组中的所有数据位、随后的密文分组，以及消息中的所有分组递归应用同样的过程。
这样，攻击者即可以解密整条消息。有趣的是，攻击者还可以采用同样的机制来加密消息。恢复一个明文字符串后，就可以修改IV来生成所选的明文字符串。ScriptResource.axd是一个最佳攻击目标。ScriptResource的d参数是一个加密的文件名。如果攻击者选择web.config作为文件名，将能够获得具体的文件，因为ASP.NET会避开IIS实施的有关文件处理方面的常规限制。例如：
注解 一般而言，以上攻击适用于任何使用PKCS #5填充的CBC密码。此类攻击最初于2002年为人们所知，它的主要目标为.NET，因为.NET对会话令牌、ViewState和ScriptResource.axd使用PKCS #5填充。请访问www.iacr.org/archive/eurocrypt2002/23320530/cbc02_e02d.pdf查阅讨论这种攻击的原始论文。
警告 通常，人们并不认真看待“绝不要公开自己的加密算法”这句话。然而，第7章介绍的位翻转攻击和上述填充提示攻击均表明，任何微不足道的漏洞都可能导致非常可怕的后果。因此，绝不要公开自己的加密算法。
http://mdsec.net/private/
由于攻击者可以利用缓冲区溢出控制易受攻击的进程，因此，这种漏洞是影响各种软件的最严重的漏洞（请参阅第16章了解相关内容）。如果攻击者能够在Web服务器中执行任意代码，他就能攻破其中运行的任何应用程序。
下面仅介绍少数几种Web服务器缓冲区溢出漏洞；但这足以证明这种漏洞的普遍性，它存在于大量Web服务器产品与组件中。
2010年，人们发现了一个漏洞。如果Apache中存在该漏洞，在遇到错误时，系统将强制从内存中卸载mod_isapi。不过，对应的函数指针仍保留在内存中，并且可以在引用相应的ISAPI函数时被调用，从而访问内存的任意部分。
有关此漏洞的详细信息，请访问：www.senseofsecurity.com.au/advisories/SOS-10-002。
Microsoft IIS 4与5包含一系列默认激活的ISAPI扩展。2001年，人们发现其中几个扩展存在缓冲区溢出漏洞，包括Internet Printing Protocol扩展与Index Server扩展。这些漏洞使攻击者能够在Local System权限下执行任意代码，进而完全控制整个计算机，并以此为基础传播Nimda与Code Red蠕虫，随后将它们迅速扩散。下面的Microsoft TechNet公告牌详细说明了这些漏洞：
www.microsoft.com/technet/security/bulletin/MS01-023.mspx；
www.microsoft.com/technet/security/bulletin/MS01-033.mspx。
七年以后
2008年，人们在IPP服务中发现了另一个漏洞。这次，部署到Windows 2003和Windows 2008上的大多数IIS版本都不会立即受到攻击，因为这些系统默认禁用该扩展。请访问www.microsoft.com/technet/security/bulletin/ms08-062.mspx查看Microsoft发布的相关建议。
2002年，人们在Apache Web服务器中发现一个由整数符号错误导致的缓冲区溢出漏洞。存在漏洞的代码被重复用在许多其他Web服务器产品中，使这些产品也受到影响。详情请访问www.securityfocus.com/bid/5033/discuss。
八年以后
2010年，人们发现Apache的mod_proxy在处理HTTP响应中的分块编码时存在整数溢出。请访问www.securityfocus.com/bid/37966了解有关此漏洞的介绍。
2003年，人们发现Windows操作系统的一个核心组件中存在缓冲区溢出漏洞。这个漏洞可被各种攻击向量利用，对许多客户而言，其中最重要的是IIS 5内置的WebDAV支持。在修复之前，这个漏洞曾被攻击者广泛利用。欲知该漏洞的详情，请访问www.microsoft.com/technet/security/bulletin/MS03-007.mspx。
七年以后
实施WebDAV导致一系列Web服务器出现漏洞。
2009年，人们发现Apache的mod_dav扩展存在另一个缓冲区溢出漏洞。欲知有关详情，请访问http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-1452。
2010年，人们发现，OPTIONS请求中的超长路径会导致Sun公司的Java System Web Server出现溢出。有关此漏洞的详情，请访问www.exploit-db.com/exploits/14287/。
如第3章所述，我们可以使用各种编码方案对不常见的字符和内容进行编码，以方便通过HTTP安全传送。如果Web应用程序中存在几种类型的漏洞，攻击者就可以利用这些编码方案避开输入确认检查，实施其他攻击。
许多Web服务器软件中都存在编码漏洞，如果用户提交的相同数据被使用各种技术的几个保护层处理，编码漏洞就会造成严重的威胁。一个典型的Web请求可能被Web服务器、应用程序平台、各种托管与非托管API、其他软件组件与基础操作系统处理。如果不同的组件以不同的方式执行一种编码方案，或者对部分编码的数据进行其他解码或注释，那么攻击者就可以利用这种行为避开过滤或造成其他反常行为。
路径遍历是可通过规范化缺陷加以利用的最常见漏洞之一，因为它总是涉及与操作系统的通信。在第10章中，我们介绍了Web应用程序中的路径遍历漏洞。各种Web服务器软件中也可能存在这种类型的漏洞，导致攻击者能够读取或写入Web根目录以外的任何文件。
Apple iDisk Server是一项流行的云同步存储服务。2009年，Jeremy Richards发现其易于受到路径遍历攻击。
iDisk用户的目录结构中包含一个公共目录，该目录的内容可由未授权的互联网用户访问。Richards发现，通过使用Unicode字符从该公共文件夹遍历来访问私有文件，即可从用户的iDisk的私有部分获取任意内容，如下所示：
此外，还可以首先提出WebDAV PROPFIND请求来列出iDisk的内容：
WEBrick是一个作为Ruby的一部分提供的Web服务器。人们发现该服务器易于受到以下简单形式的遍历攻击：
欲知该漏洞的详情，请访问www.securityfocus.com/bid/28123。
此路径遍历漏洞源于JVM并不解码UTF-8这一事实。Tomcat即是一种以Java编写并使用易受攻击的JVM版本的Web服务器。使用UTF-8编码的../序列可从中检索任意内容：
欲知该漏洞的详情，请访问http://tomcat.apache.org/security-6.html。
2001年，人们在Allaire JRun中发现一个漏洞，即使目录中包含index.html之类的默认文件，攻击者仍然可以利用这个漏洞获取目录列表。攻击者可以使用以下形式的URL获取目录列表：
%3f是问号的URL编码形式，它常用在查询字符串的开始部分。漏洞之所以产生，是因为最初URL解析器并未将%3f解释为查询字符串指示符。因此，服务器认为URL以.jsp结尾，将请求提交给负责JSP文件请求的组件处理。然后，这个组件对%3f进行解码，把它解释为查询字符串的开始部分，并发现得到的基础URL不是一个JSP文件，于是它返回目录列表。欲知详情，请访问www.securityfocus.com/bid/3592。
八年以后
2009年，人们发现，在目录名以问号结尾时，Jetty中存在一个目录遍历相关的类似低风险漏洞。要解决此漏洞，需要将? 编码为%3f。欲知详情，请访问https://www.kb.cert.org/vuls/id/402580。
Microsoft IIS服务器中的两个相关漏洞分别于2000年与2001年被发现。为防止路径遍历攻击，IIS在包含点－点－斜线序列的请求中查找它的字面量与URL编码形式。如果某个请求中没有这些表达式，IIS服务器就会接受这个请求，然后做进一步处理。但是，接下来，服务器对被请求的URL进行了额外的规范化处理，使得攻击者能够避开过滤，让服务器处理遍历序列。
在第一个漏洞中，攻击者可以提交点－点－斜线序列的各种非法Unicode编码形式，如..%c0%af。这个表达式与IIS的前沿过滤器（upfront filter）并不匹配，但随后的处理过程接受这种非法编码，并将它转换成一个字面量遍历序列。这使攻击者能够侵入Web根目录以外的目录，并使用下面的URL执行任意命令：
在第二个漏洞中，攻击者可以提交点－点－斜线序列的双重编码形式，如..%255c。同样，这个表达式也与IIS的过滤器不相匹配，但随后的处理过程对输入进行“过剩解码”（superfluous decode），因而将其转换成一个字面量遍历序列。这样，攻击者就可以使用下面的URL实施另一次攻击：
欲知这些漏洞的详情，请访问：
www.microsoft.com/technet/security/bulletin/MS00-078.mspx
www.microsoft.com/technet/security/bulletin/MS01-026.mspx
九年以后
2009年，人们又在WebDAV中发现类似的IIS漏洞，这说明Web服务器软件中的编码与规范化漏洞始终是一个安全隐患。受IIS保护的文件可以通过在URL中插入恶意%c0%af字符串进行下载。
由于以下请求看起来并不是一个针对受保护文件的请求，ISS会授权其访问相关资源的权限，但恶意字符串随后会从请求中删除：
Translate: f消息头用于确保该请求会由WebDAV扩展处理。使用以下代码可以在WebDAV请求中直接实施相同的攻击：
欲知详情，请访问www.securityfocus.com/bid/34993/。
前面我们提到，可通过Oracle的PL/SQL网关访问危险默认功能。为解决这个问题，Oracle创建了PL/SQL排除列表（Exclusion List），它阻止攻击者访问以某些表达式（如OWA与SYS）开头的包。
2001～2007年以来，David Litchfield发现了一系列避开PL/SQL排除列表的方法。在第一个漏洞中，在包名称前插入空白符（如换行符、空格或制表符）即可避开过滤。例如：
这个URL可避开过滤，由于后端数据库忽略空白符，因此危险的包得以执行。
在第二个漏洞中，用代表字符ÿ的%FF替代字母Y，即可避开过滤：
这个URL可避开过滤，后端数据库对字符进行规范化处理，将其恢复到标准的字母Y，从而调用危险的包。
在第三个漏洞中，用双引号包含一个被阻止的表达式即可避开过滤：
这个URL可避开过滤，后端数据库接受被引用的包名称，意味着它可调用危险的包。
在第四个漏洞中，使用尖括号在被阻止的表达式前放置一个编程的goto标签，即可避开过滤：
这个URL可避开过滤，后端数据库忽略goto标签，使得危险的包得以执行。
由于前端过滤由一个组件根据简单的文本模式匹配执行，而随后的处理过程却由另一个组件执行，并且它们按照自己的规则解释输入的句法与语法意义，因而造成了以上各种漏洞。这两组规则之间的任何差异都可能会被攻击者利用，提交与过滤器所使用的模式不相匹配的输入，但数据库却按攻击者希望的方式解释这个输入，调用危险的包。由于Oracle数据库的功能极其强大，因而这种差异大量存在。
欲知这些漏洞的详情，请访问：
www.securityfocus.com/archive/1/423819/100/0/threaded
The Oracle Hacker's Handbook，作者David Litchfield（Wiley，2007）
七年以后
2008年，人们在Portal Server（Oracle Application Server的一部分）中发现一个漏洞：如果攻击者具有以%0A结尾的会话ID cookie值，就可以避开“基本验证”检查。
如果运气不错的话，有的渗透测试员会在所针对的Web服务器中找到本章描述的一些漏洞。然而，它们很可能已经升级到了最新的版本，渗透测试员需要查找一些当前或最新的漏洞，利用它们攻击服务器。
在Web服务器等非定制产品中查找漏洞时，使用自动化扫描工具是一个不错的起点。与Web应用程序这些定制产品不同，几乎所有的Web服务器都使用第三方软件，并且有无数用户已经以相同的方式安装和配置了这些软件。在这种情况下，使用自动化扫描器发送大量专门设计的请求并监控表示已知漏洞的签名，就可以迅速、高效地确定最明显的漏洞。Nessus是一款非常不错的免费漏洞扫描器，当然也可以使用各种商业扫描器。
除使用扫描工具外，渗透测试员还应始终对所攻击的软件进行深入研究。同时，浏览Security Focus、OSVDB、邮件列表Bugtraq和Full Disclosure等资源，在目标软件上查找所有最近发现的、尚未修复的漏洞信息。同时，别忘记查看Exploit Database和Metasploit，看看是不是有人已经做了相关工作，并发现了相应的漏洞。下面的网址或许能帮到你：
www.exploit-db.com
www.metasploit.com/
www.grok.org.uk/full-disclosure/
http://osvdb.org/search/advsearch
还要注意，一些Web应用程序产品中内置了开源Web服务器，如Apache或Jetty。因为管理员把服务器看作他们所安装的应用程序，而不是他们负责的基础架构的一部分，所以这些捆绑服务器的安全更新也应用得相对较为缓慢。而且，在这种情况下，标准的服务标题也已被修改。因此，对所针对的软件进行手动测试与研究，可以非常有效地确定自动化扫描工具无法发现的漏洞。
如有可能，渗透测试员应该考虑在本地安装所攻击的软件，并自己进行测试，查找任何尚未发现的新漏洞或广泛流传的漏洞。
从某种程度上讲，部署第三方Web服务器产品的组织的命运掌握在软件供应商手中。然而，具有安全意识的组织仍然可以采取大量有用的措施保护自己，避开本章描述的各种软件漏洞。
并非所有软件产品与供应商都提供同等优良的服务。分析几种不同的服务器产品的最近历史可以发现，它们在存在的严重漏洞数量、供应商修复这些漏洞是否及时以及发布的补丁在随后测试过程中表现的适应性等方面存在明显的差异。在选择部署何种Web服务器软件之前，应该研究这些差异，并考虑如果所在的组织采用了选择的软件，它在近几年将会如何运转。
任何有责任的软件供应商必须定期发布安全更新。有时，这些补丁能够解决供应商自身在内部发现的问题；其他情况下，软件问题由专门的研究员上报，但我们无法确定他是否保留了一些信息。其他漏洞因为被攻击者广泛利用，因而引起供应商的注意。但是，无论是上述哪一种情况，一旦供应商发布补丁，任何强大的逆向工程方法都能立即查明它所解决的问题所在，使攻击者能够着手设计利用这个问题的攻击。因此，如果可行，应尽可能及时地应用安全补丁。
大多数Web服务器都拥有大量的配置选项，可控制在其中激活哪些功能，同时控制它们的运行状态。如果无用的功能（如默认ISAPI扩展）仍然被激活，那么只要攻击者在这项功能中发现新的漏洞，服务器就会受到严重的攻击威胁。用户应该查阅与所使用的软件有关的强化指南，同时还应考虑采用以下这些常用的强化步骤。
禁用任何不需要的内置功能，配置剩下的功能尽可能严格地运行，与商业需求保持一致。这包括删除映射的文件扩展名、Web服务器模块和数据库组件。可以使用IIS Lockdown等工具迅速完成这项任务。
如果应用程序由任何其他以本地代码开发的定制服务器扩展组成，则应考虑是否可以使用托管代码重新编写这些扩展。如果不能，则应确保托管代码环境先执行其他输入确认，然后再将输入传递给这些功能。
可以对需要保留的许多功能与资源进行重命名，以防止攻击者利用它们实施另一层障碍。即使技术熟练的攻击者仍然能够发现重命名后的名称，但这种模糊处理可以阻止攻击者新手与自动化蠕虫。
在整个技术栈中应用最低权限原则。例如，应配置Web服务器进程使用最低权限的操作系统账户。还可以在UNIX系统上使用chroot环境进一步限制任何攻击的影响范围。
应指派一名组织职员负责监控Bugtraq与Full Disclosure等资源，查找与所使用的软件中新发现的漏洞有关的公告与讨论。还可以预订各种私人服务，由他们提供软件中已经发现但尚未公开披露的最新漏洞通知。通常，如果了解与某个漏洞有关的技术细节，就可以在供应商发布完整的补丁前，有效地修改这个漏洞。
应该始终实施几层保护，减轻基础架构组件中的任何安全违反造成的影响。可以采取各种措施，将针对Web服务器的成功攻击的影响限制在局部范围内。即使Web服务器被完全攻破，这些措施也让用户有足够的时间防止任何严重的数据泄露。
可以限制Web服务器访问其他自治的应用程序组件。例如，应只允许应用程序使用的数据库账户INSERT访问用于保存审计日志的表；这意味着，即使攻击者攻破Web服务器，他也无法删除已经创建的任何日志记录。
可以对进出Web服务器的流量实施严格的网络级过滤。
可以使用一个入侵检测系统确定任何表明发生安全违反的反常网络活动。攻破Web服务器后，许多攻击者会立即尝试建立反向连接，侵入因特网，或者扫描DMZ网络中的其他主机。高效的入侵检测系统将实时通知这些事件，以便用户采取措施阻止攻击。
许多应用程序都受到某种外部组件的保护，这些组件或者位于应用程序所在的同一主机上，或者位于基于网络的设备上；它们要么执行入侵防御（应用程序防火墙），要么执行入侵检测（如传统的入侵检测系统）。由于这类设备用于确定攻击的方法基本类似，因此，我们将把它们当做同一类设备看待。虽然许多人认为安装这类设备总比什么都不做要强，但是，许多时候，它们会造成一种错误的安全意识，人们觉得：既然实施了另一层防御，安全状况将会自动改善。虽然此类系统并不会降低安全防御，并且可以阻止目标明确的攻击（如因特网蠕虫），但在许多情况下，它并不像人们认为的那样能够显著改善安全状况。
值得注意的是，除非此类防御设备采用大量定制规则，否则它们并不能防御我们在第4～8章中讨论的任何漏洞，并且在防范业务逻辑中的潜在漏洞（第11章）方面也没有任何实际用途。同时，它们也无法防范某些特定的攻击，如基于DOM的XSS（第12章）。至于其他漏洞（利用这些漏洞的攻击会表现出某种攻击模式），以下问题通常会降低Web应用程序防火墙的用处。
如果防火墙过于严格地遵循HTTP规范，它可能会对应用程序服务器如何处理请求做出假设。相反，网络层防御中的防火墙或IDS设备通常并不了解某些HTTP传输方法的细节。
请求通过防火墙后，在处理请求的过程中，应用程序服务器本身可能会修改用户输入，如对其进行解码、添加转义字符，或过滤掉特定字符串。前几章中介绍的许多攻击步骤均以避开输入确认为目标，应用程序层防火墙可能易于受到类似的攻击。
许多防火墙和IDS警报基于特定的常见攻击有效载荷，而不是基于利用漏洞的常规方法。如果攻击者能够检索文件系统中的任意文件，针对/manager/viewtempl?loc=/etc/passwd的请求可能会被阻止，但针对/manager/viewtempl?loc=/var/log/syslog的请求并不会被视为攻击，即使其内容可能对攻击者更加有用。
从整体看，我们并不需要区分全局输入确认过滤器、基于主机的代理或基于网络的Web应用程序防火墙。以下步骤适用于所有设备。
可以使用以下步骤推断是否安装了Web应用程序防火墙。
（1）在参数值中使用明确的攻击有效载荷向应用程序（最好是响应中包含名称或值的某个应用程序位置）提交任意参数名称。如果应用程序阻止该攻击，这可能是由于外部防御机制所致。
（2）如果可以提交在服务器响应中返回的变量，则提供一系列模糊测试字符串及这些字符串的编码形式可以确定应用程序的用户输入防御行为。
（3）对应用程序中的变量实施相同的攻击来确认这一行为。
在尝试避开Web应用程序防火墙时，可以提交以下字符串。
（1）对于所有模糊测试字符串和请求，使用标准签名数据库中不可能存在的良性字符串作为有效载荷。根据定义，我们不可能提供这些字符串的示例。但是，在进行文件检索时，应避免将/etc/passwd或/windows/system32/config/sam作为有效载荷。此外，应在XSS攻击中避免使用<script>，并避免将alert()或xss用作XSS有效载荷。
（2）如果特定请求被阻止，可以尝试在其他位置或上下文中提交相同的参数。例如，在GET请求的URL中、在POST请求主体中，以及在POST请求的URL中提交相同的参数。
（3）此外，应尝试在ASP.NET上将参数作为cookie提交。如果在查询字符串或消息主体中找不到参数foo，API Request.Params[“foo”]会检索名为foo的cookie的值。
（4）回顾第4章中介绍的引入用户输入的所有其他方法，选择其中任何不受保护的方法。
（5）确定以非标准格式（如序列化或编码）或可能以此类格式提交用户输入的位置。如果找不到此类位置，可以通过串联字符串和/或将字符串分布到多个参数中来构建攻击字符串。（注意，如果目标是ASP.NET，可以使用HPP通过同一变量的各种变体来串联攻击字符串。）
许多部署了Web应用程序防火墙或IDS的组织并没有根据本节介绍的方法对防御设备进行有针对性的测试，因此，在针对此类设备实施攻击时，以上方法通常能够奏效。
与Web应用程序上运行的其他组件一样，Web服务器也是一个重要的受攻击面，通过它攻击者可以攻破整个应用程序。Web服务器中的漏洞可使攻击者访问目录列表、可执行页面的源代码、敏感配置和运行时间数据，并避开输入过滤，直接威胁应用程序的安全。
由于存在大量各种各样的Web服务器产品与版本，查找Web服务器漏洞往往需要我们进行一定程度的探索与研究。但是，使用自动化扫描工具可以迅速高效地确定所攻击的服务器的配置与软件中的任何已知漏洞。
欲知问题答案，请访问http://mdsec. net/wahh。
（1）在什么情况下Web服务器会显示目录列表？
（2）WebDAV方法有什么作用？为什么说它们会造成危险？
（3）如何利用一个配置成Web代理服务器的Web服务器？
（4）何为Oracle PL/SQL排除列表?如何避开这个列表？
（5）如果一个Web服务器允许通过HTTP与HTTPS访问它的功能，当查询漏洞时，使用其中一个协议与使用另一个协议相比有哪些优点？
Copyright ©2010-2022 比特日记 All Rights Reserved.