4.1.4 测试 Web 应用程序漏洞

测试 Web 应用程序漏洞

ID
WSTG-INFO-04

总结
测试 Web 应用程序漏洞的一个重要步骤是找出 Web 服务器上托管了哪些特定应用程序。许多应用程序具有已知的漏洞和已知的攻击策略，可以利用这些漏洞和攻击策略来获得远程控制或利用数据。此外，许多应用程序经常配置错误或未更新，因为人们认为它们仅在“内部”使用，因此不存在威胁。
随着虚拟 Web 服务器的激增，IP 地址和 Web 服务器之间的传统 1：1 类型关系正在失去其原有的大部分意义。具有多个站点或应用程序的符号名称解析为同一 IP 地址的情况并不少见。此方案不仅限于托管环境，也适用于普通企业环境。

安全专业人员有时会被提供一组 IP 地址作为测试目标。可以说，这种情况更类似于渗透测试类型的参与，但无论如何，预计这样的分配将测试通过此目标访问的所有 Web 应用程序。问题在于给定的 IP 地址在端口 80 上托管 HTTP 服务，但如果测试人员应该通过指定 IP 地址（这是他们所知道的全部）来访问它，它会报告“此地址未配置任何 Web 服务器”或类似消息。但是该系统可以“隐藏”许多与不相关的符号（DNS）名称相关联的Web应用程序。显然，分析的程度会受到很大的影响，这取决于测试人员是测试所有应用程序还是只测试他们知道的应用程序。

有时，目标规范更丰富。可以向测试人员提供IP地址及其相应的符号名称列表。然而，此列表可能会传达部分信息，即，它可以省略一些符号名称，而客户甚至可能不知道这一点（这更有可能发生在大型组织中）。

影响评估范围的其他问题由发布在不明显的URL上的Web应用程序（例如，http://www.example.com/some-strange-URL）表示，这些URL在其他地方没有引用。这可能是由于错误（由于配置错误）或故意（例如，未播发的管理界面）而发生的。

若要解决这些问题，必须执行 Web 应用程序发现。

测试目标

• 枚举 Web 服务器上存在的范围内的应用程序。

如何测试

Web 应用程序发现是一个旨在识别给定基础结构上的 Web 应用程序的过程。后者通常被指定为一组 IP 地址（可能是网络块），但可能包含一组 DNS 符号名称或两者的混合。此信息在执行评估之前分发，无论是经典风格的渗透测试还是以应用程序为中心的评估。在这两种情况下，除非参与规则另有规定（例如 http://www.example.com/，仅测试位于URL的应用程序），否则评估应力求范围最全面，即应确定通过给定目标可访问的所有应用程序。以下示例检查可用于实现此目标的一些技术。

以下一些技术适用于面向互联网的Web服务器，即DNS和反向IP基于Web的搜索服务以及搜索引擎的使用。示例使用专用 IP 地址（例如192.168.1.100），除非另有说明，否则这些地址表示通用 IP 地址，仅用于匿名目的。

有三个因素会影响与给定 DNS 名称（或 IP 地址）相关的应用程序数量：

不同的基本网址

1. 不同的基本网址
   Web应用程序的明显入口点是，即 www.example.com，使用这种速记符号，我们认为Web应用程序起源于http://www.example.com/（这同样适用于HTTPS）。但是，即使这是最常见的情况，也没有任何内容强制应用程序从/启动。

例如，相同的符号名称可能与三个 Web 应用程序相关联，例如： http://www.example.com/app1 http://www.example.com/app2 http://www.example.com/app3

在这种情况下，URL 不会与有意义的页面相关联。这三个应用程序将保持隐藏状态，除非测试人员明确知道如何访问它们，即测试人员知道 app1、app2或 app3。通常不需要以这种方式发布 Web 应用程序，除非所有者不希望以标准方式访问它们，并准备通知用户它们的确切位置。这并不意味着这些应用程序是秘密的，只是它们的存在和位置没有明确公布。

2. 非标端口
   虽然 Web 应用程序通常位于端口 80 （HTTP） 和 443 （HTTPS） 上，但这些端口号没有任何固定或强制性的。实际上，Web 应用程序可以与任意 TCP 端口相关联，并且可以通过指定端口号来引用，如下所示：http[s]://www.example.com:port/。例如 http://www.example.com:20000/。

3. 虚拟主机
   DNS 允许将单个 IP 地址与一个或多个符号名称相关联。例如，IP 地址 192.168.1.100 可能与 DNS 名称 www.example.com, helpdesk.example.com, webmail.example.com相关联。不必所有名称都属于同一 DNS 域。这种 1 到 N 的关系可以反映为通过使用所谓的虚拟主机来提供不同的内容。指定我们所指的虚拟主机的信息嵌入在 HTTP 1.1 主机标头中。

www.example.com除了显而易见的，除非他们知道helpdesk.example.com 和 webmail.example.com。

解决问题 1 的方法 - 非标准网址

无法完全确定是否存在非标准命名的 Web 应用程序。作为非标准的，没有固定的标准来管理命名约定，但是测试人员可以使用许多技术来获得一些额外的见解。

首先，如果 Web 服务器配置错误并允许目录浏览，则可能会发现这些应用程序。漏洞扫描程序在这方面可能会有所帮助。

其次，这些应用程序可能被其他网页引用，并且它们有可能被网络搜索引擎抓取和索引。如果测试人员怀疑www.example.com 存在此类隐藏应用程序，他们可以使用站点操作员进行搜索 site: www.example.com并检查查询结果。在返回的 URL 中，可能有一个指向这种不明显的应用程序。

另一种选择是探测可能成为未发布应用程序的候选 URL。例如，可以从https://www.example.com/webmail 、https://webmail.example.com/ 或 https://mail.example.com/ 等 URL 访问 Web 邮件前端。这同样适用于管理接口，这些接口可能发布在隐藏的 URL（例如，Tomcat 管理界面）上，但未在任何地方引用。因此，做一些字典式的搜索（或“智能猜测”）可能会产生一些结果。漏洞扫描程序在这方面可能会有所帮助。

解决问题 2 的方法 - 非标准端口

很容易检查非标准端口上是否存在 Web 应用程序。端口扫描器（如 Nmap）能够通过-sV 该选项执行服务识别，并将识别任意端口上的 http[s] 服务。需要对整个 64k TCP 端口地址空间进行完全扫描。

例如，以下命令将通过TCP连接扫描查找IP 192.168.1.100 上的所有开放端口，并尝试确定哪些服务绑定到它们（仅显示必要的交换机 - Nmap具有广泛的选项集，其讨论超出了范围）：

nmap –Pn –sT –sV –p0-65535 192.168.1.100

检查输出并查找 HTTP 或 TLS 包装服务的指示（应探测以确认它们是 HTTPS）就足够了。例如，上一个命令的输出可能如下所示：

Interesting ports on 192.168.1.100:
(The 65527 ports scanned but not shown below are in state: closed)
PORT      STATE SERVICE     VERSION
22/tcp    open  ssh         OpenSSH 3.5p1 (protocol 1.99)
80/tcp    open  http        Apache httpd 2.0.40 ((Red Hat Linux))
443/tcp   open  ssl         OpenSSL
901/tcp   open  http        Samba SWAT administration server
1241/tcp  open  ssl         Nessus security scanner
3690/tcp  open  unknown
8000/tcp  open  http-alt?
8080/tcp  open  http        Apache Tomcat/Coyote JSP engine 1.1

从这个例子中，可以看到：

• 端口 80 上运行着一个 Apache HTTP 服务器。
• 看起来端口 443 上有一个 HTTPS 服务器（但这需要确认，例如https://192.168.1.100 ，通过使用浏览器访问）。
• 在端口901上有一个Samba SWAT网页界面。
• 端口 1241 上的服务不是 HTTPS，而是 TLS 包装的 Nessus 守护程序。
• 端口 3690 具有未指定的服务（Nmap 返回其指纹 - 为清楚起见，此处省略 - 以及提交它以合并到 Nmap 指纹数据库中的说明，前提是您知道它代表哪个服务）。
• 端口 8000 上的另一个未指定的服务;这可能是HTTP，因为在此端口上找到HTTP服务器并不少见。让我们研究一下这个问题：

$ telnet 192.168.10.100 8000
Trying 192.168.1.100...
Connected to 192.168.1.100.
Escape character is '^]'.
GET / HTTP/1.0

HTTP/1.0 200 OK
pragma: no-cache
Content-Type: text/html
Server: MX4J-HTTPD/1.0
expires: now
Cache-Control: no-cache

<html>
...

这证实了它实际上是一个HTTP服务器。或者，测试人员可以使用网络浏览器访问 URL;或者使用 GET 或 HEAD Perl 命令，这些命令模仿上面给出的 HTTP 交互（但是并非所有服务器都接受 HEAD 请求）。

• Apache Tomcat 在端口 8080 上运行。

漏洞扫描程序可以执行相同的任务，但首先检查所选扫描程序是否能够识别在非标准端口上运行的 HTTP[S] 服务。例如，Nessus 能够在任意端口上识别它们（前提是指示它扫描所有端口），并且对于 Nmap，将针对已知的 Web 服务器漏洞以及 HTTPS 服务的 TLS/SSL 配置提供许多测试。如前所述，Nessus 还能够发现可能被忽视的流行应用程序或 Web 界面（例如，Tomcat 管理界面）。

解决问题 3 的方法 - 虚拟主机

有许多技术可用于识别与给定IP地址x.y.z.t关联的DNS名称。

DNS 区域传输

鉴于 DNS 服务器在很大程度上不接受区域传输，这种技术的使用现在有限。但是，它仍然值得尝试。首先，测试人员必须确定服务的名称服务器 x.y.z.t.如果符号名称已知 x.y.z.t （顺其自然www.example.com），则可以通过 nslookup, host, or dig等工具通过请求 DNS NS 记录来确定其名称服务器。

如果x.y.z.t 没有已知的符号名称，但目标定义至少包含一个符号名称，则测试人员可能会尝试应用相同的过程并查询该名称的名称服务器（希望该名称服务器也能提供该名称服务器）。例如，如果目标由 IP 地址x.y.z.t 和mail.example.com名称组成，则确定域 example.com的名称服务器。

以下示例演示如何使用以下host 命令标识其www.owasp.org名称服务器：

$ host -t ns www.owasp.org
www.owasp.org is an alias for owasp.org.
owasp.org name server ns1.secure.net.
owasp.org name server ns2.secure.net.

现在可以请求向 example.com域的名称服务器进行区域传输。如果测试人员很幸运，他们可能会收到此域的 DNS 条目列表作为响应。这将包括显而易见的 www.example.com 和不太明显的helpdesk.example.com和webmail.example.com （可能还有其他的）。检查区域传输返回的所有名称，并考虑与正在评估的目标相关

尝试从其名称owasp.org服务器之一请求区域传输：

$ host -l www.owasp.org ns1.secure.net
Using domain server:
Name: ns1.secure.net
Address: 192.220.124.10#53
Aliases:

Host www.owasp.org not found: 5(REFUSED)
; Transfer failed.

DNS 反向查询

此过程与上一个过程类似，但依赖于反向 （PTR） DNS 记录。尝试将记录类型设置为 PTR 并对给定的 IP 地址发出查询，而不是请求区域传输。如果测试人员幸运，他们可能会收到 DNS 名称条目作为响应。此技术依赖于 IP 到符号名称映射的存在，这不能保证。

基于 Web 的 DNS 搜索

这种搜索类似于 DNS 区域传输，但依赖于基于 Web 的服务，这些服务在 DNS 上启用基于名称的搜索。其中一项服务是Netcraft Search DNS服务。测试人员可能会查询属于您选择的域的名称列表，例如example.com 。然后，他们将检查他们获得的名称是否与他们正在检查的目标相关。

反向 IP 服务

反向 IP 服务类似于 DNS 反向查询，不同之处在于测试人员查询基于 Web 的应用程序而不是名称服务器。有许多这样的服务可用。由于它们倾向于返回部分（通常是不同的）结果，因此最好使用多个服务来获得更全面的分析。

Mx工具箱反向IP
DNSstuff（提供多种服务）
Net Square（对域和IP地址的多个查询，需要安装）

• MxToolbox Reverse IP(Mx工具箱反向IP)
• DNSstuff (提供多种服务)
• Net Square 对域和IP地址的多个查询，需要安装)

谷歌搜索
在从以前的技术中收集信息之后，测试人员可以依靠搜索引擎来优化和增加他们的分析。这可能会产生属于目标的其他符号名称或通过非明显 URL 访问的应用程序的证据。

例如，考虑到前面关于www.owasp.org的示例，测试人员可以查询 Google 和其他搜索引擎，查找与新发现的 webgoat.org, webscarab.com, 和webscarab.net的域相关的信息（因此，DNS 名称）。

谷歌搜索技术在测试：蜘蛛、机器人和爬虫中进行了解释。

数字证书

如果服务器接受通过 HTTPS 的连接，则证书上的公用名 （CN） 和使用者备用名称 （SAN） 可能包含一个或多个主机名。但是，如果 Web 服务器没有受信任的证书，或者正在使用通配符，则可能不会返回任何有效信息。

CN 和 SAN 可以通过手动检查证书或通过其他工具（如 OpenSSL）获得：

openssl s_client -connect 93.184.216.34:443 </dev/null 2>/dev/null | openssl x509 -noout -text | grep -E 'DNS:|Subject:'

Subject: C = US, ST = California, L = Los Angeles, O = Internet Corporation for Assigned Names and Numbers, CN = www.example.org
DNS:www.example.org, DNS:example.com, DNS:example.edu, DNS:example.net, DNS:example.org, DNS:www.example.com, DNS:www.example.edu, DNS:www.example.net

工具

• DNS 查找工具，例如 nslookup, dig 和 similar等。
• 搜索引擎（谷歌、必应和其他主要搜索引擎）。
• 与 DNS 相关的基于 Web 的专用搜索服务：请参阅文本。
• Nmap
• Nessus Vulnerability Scanner
• Nikto