2019测试指南-web应用程序安全测试（二）在Web服务器上枚举应用程序

最新推荐文章于 2021-08-05 13:36:44 发布

weixin_33782386

最新推荐文章于 2021-08-05 13:36:44 发布

阅读量614

点赞数

原文链接：https://my.oschina.net/u/3447023/blog/3017496

版权

2019独角兽企业重金招聘Python工程师标准>>>

测试Web应用程序漏洞的最重要步骤是找出Web服务器上托管的特定应用程序。许多应用程序都具有已知的漏洞和已知的攻击策略，可以利用这些策略来获取远程控制或利用数据。此外，许多应用程序经常被错误配置或未更新，因为他们认为它们仅在“内部”使用，因此不存在威胁。

随着虚拟Web服务器的普及，IP地址和Web服务器之间传统的1：1类型关系正在失去其原有的重要意义。拥有符号名称解析为同一IP地址的多个网站或应用程序并不罕见。此方案不仅限于托管环境，也适用于普通的企业环境。

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

有时，目标规范更丰富。可以给测试者一个IP地址列表及其相应的符号名称。然而，这个列表可能会传达部分信息，即它可能会省略一些符号名称，而客户可能甚至都没有意识到这一点（这种情况更有可能发生在大型组织中）。

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

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

测试目标

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

如何测试

黑盒测试

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

注意：以下某些技术适用于面向Internet的Web服务器，即DNS和反向IP基于Web的搜索服务以及搜索引擎的使用。示例使用私有IP地址（例如192.168.1.100），除非另有说明，否则它们代表通用 IP地址，仅用于匿名用途。

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

1.不同的基本URL
Web应用程序的明显入口点是www.example.com，即使用这种简写表示法，我们会想到源自http://www.example.com/的Web应用程序（同样适用于https））。但是，即使这是最常见的情况，也没有什么强迫应用程序以“/”开头。

例如，相同的符号名称可以与三个Web应用程序相关联，例如：http ： //www.example.com/url1 http://www.example.com/url2 http://www.example.com/url3

在这种情况下，URL http://www.example.com/不会与有意义的页面相关联，并且三个应用程序将被“隐藏”，除非测试人员明确知道如何访问它们，即测试人员知道url1，url2或url3。通常不需要以这种方式发布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 Host： header [1]中。

除了明显的www.example.com之外，人们不会怀疑是否存在其他Web应用程序，除非他们知道helpdesk.example.com和webmail.example.com。

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

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

其次，这些应用程序可能被其他网页引用，并且它们有可能被网络搜索引擎抓取并编入索引。如果测试人员怀疑www.example.com上存在此类“隐藏”应用程序，他们可以使用网站运营商进行搜索并检查“site：www.example.com”的查询结果。在返回的URL中，可能有一个指向这种非显而易见的应用程序。

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

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

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

nmap -PN -sT -sV -p0-65535 192.168.1.100

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

192.168.1.100上有趣的端口：
（已扫描但未显示的65527端口处于状态：已关闭）
港口国服务版
22 / tcp open ssh OpenSSH 3.5p1（协议1.99）
80 / tcp打开http http httpd 2.0.40（（Red Hat Linux））
443 / tcp open ssl OpenSSL
901 / tcp打开http Samba SWAT管理服务器
1241 / tcp打开ssl Nessus安全扫描程序
3690 / tcp打开未知
8000 / tcp打开http-alt？
8080 / tcp打开http Apache Tomcat / Coyote JSP引擎1.1

从这个例子中，人们看到：

在端口80上运行Apache http服务器。
看起来端口443上有一个https服务器（但需要确认，例如，通过浏览器访问https://192.168.1.100）。
在端口901上有一个Samba SWAT Web界面。
端口1241上的服务不是https，而是SSL包装的Nessus守护程序。
端口3690具有未指定的服务（为了清楚起见，nmap返回其指纹 - 以及提交它以便在nmap指纹数据库中合并的说明，前提是您知道它代表哪个服务）。
端口8000上另一个未指定的服务; 这可能是http，因为在这个端口上找到http服务器并不罕见。我们来看看这个问题：

$ telnet 192.168.10.100 8000
试试192.168.1.100 ......
连接到192.168.1.100。
逃脱角色是'^]'。
GET / HTTP / 1.0

HTTP / 1.0 200 OK
编译指示：无缓存
内容类型：text / html
服务器：MX4J-HTTPD / 1.0
到期：现在
缓存控制：无缓存

<HTML>
...

这证实了它实际上是一个HTTP服务器。或者，测试人员可以使用Web浏览器访问URL; 或使用GET或HEAD Perl命令，它们模仿HTTP交互，例如上面给出的那些（但是HEAD请求可能不被所有服务器遵守）。

Apache Tomcat在端口8080上运行。

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

解决问题3的方法 - 虚拟主机
有许多技术可用于识别与给定IP地址xyzt相关联的DNS名称。

DNS区域传输
由于区域传输在很大程度上不受DNS服务器的支持，因此现在这种技术的使用受到限制。但是，它可能值得一试。首先，测试人员必须确定服务于xyzt的名称服务器。如果已知xyzt的符号名称（让它为www.example.com），则可以通过请求DNS NS记录，通过nslookup，host或dig等工具确定其名称服务器。

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

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

$ host -t ns www.owasp.org
www.owasp.org是owasp.org的别名。
owasp.org名称服务器ns1.secure.net。
owasp.org名称服务器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
使用域服务器：
名称：ns1.secure.net
地址：192.220.124.10＃53
别名：

主持人www.owasp.org未找到：5（REFUSED）
; 转移失败。

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

基于Web的DNS搜索
此类搜索类似于DNS区域传输，但依赖于基于Web的服务，可在DNS上启用基于名称的搜索。其中一项服务是Netcraft搜索DNS服务，可从http://searchdns.netcraft.com/?host获得。测试人员可以查询属于您选择的域的名称列表，例如example.com。然后他们将检查他们获得的名字是否与他们正在检查的目标相关。

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

域名工具反向IP：http：//www.domaintools.com/reverse-ip/ （需要免费会员资格）

MSN搜索：http：//search.msn.com 语法：“ip：xxxx”（不带引号）

网站托管信息：http ：//whois.webhosting.info/语法：http：//whois.webhosting.info/xxxx

DNSstuff：http：//www.dnsstuff.com/ （提供多种服务）

http://www.net-square.com/mspawn.html （对域和IP地址的多个查询，需要安装）

tomDNS：http：//www.tomdns.net/index.php （在撰写本文时，某些服务仍然是私有的）

SEOlogs.com：http://www.seologs.com/ip-domains.html （反向IP /域查找）

以下示例显示了对上述反向IP服务之一的查询结果216.48.3.18，即www.owasp.org的IP地址。已经揭示了映射到同一地址的另外三个非显而易见的符号名称。