|
通过使用搜索引擎、扫描器、发送简单的HTTP请求或者专门精心制作的请求，都有可能导致应用程序泄漏诸如错误信息、版本信息以及所使用的技术等信息。
一、测试robots.txt文件
现在，我们首先介绍如何测试robots.txt文件。Web蜘蛛/机器人/爬虫可以用来检索网页，并沿着超链接进一步探索更多、更深的Web内容。当然，网站可以在根目录放上一个robots.txt文件，这样就可以规定哪些Web蜘蛛行为是站点可以接受的，那些是禁止的。
举例来说，我们可以看一下http://www.google.com/robots.txt的内容片断：
伪指令User-Agent表示具体的Web蜘蛛/机器人/网络爬虫。例如User-Agent:Googlebot 表示GoogleBot网络爬虫，而User-Agent:* 泛指所有的Web蜘蛛/机器人/网络爬虫：
伪指令Disallow的作用是规定哪些资源对蜘蛛/机器人/网络爬虫来说是禁用的。在上面的例子中，禁止蜘蛛访问下列目录：
Web蜘蛛/机器人/网络爬虫可以故意忽略robots.txt文件中的“禁令”。因此，不要把robots.txt当成是限制第三方访问、存储或者转帖web内容的灵丹妙药。
下面是针对robots.txt文件的黑盒子测试及用例：
Wget
Robots.txt文件可以从Web服务器的web根目录下找到。比如，可以使用wget检索www.google.com站点中的robots.txt，如下所示：
使用Google Webmaster Tools分析robots.txt
Google的Google Webmaster Tools提供了一个robots.txt分析功能，所以，在渗透测试时我们可以利用它来分析robots.txt，具体方法如下所示：
1. 用Google帐户登陆Google Webmaster Tools。
2. 在Dashboard上，单击想要分析的站点URL。
3. 单击Tools按钮，然后单击Analyze robots.txt。
二、利用搜索引擎进行侦察
下面将介绍如何搜索Google Index 并从Google Cache中删除有关的web内容。我们知道，GoogleBot一旦完成爬行过程，它就会根据标签和有关属性（诸如
Bad request Your browser sent to query this server could not understand. |
来自SunONE 6.1的响应：
$ nc sunone.example.com 80 GET / JUNK/1.0 Bad request Your browser sent a query this server could not understand. |
自动测试方法
获取Web服务器指纹的方法有多种。上面介绍的是手动方法，下面介绍一些通过工具自动进行的测试方法。其中，httprint就是这样一种工具。Httprint具有一个特征码字典，籍此可以识别目标服务器的类型和版本。下图是一个用法示例：
 |
| 图3 |
联机测试
在线工具的一个例子Netcraft，它能带给我们大量目标服务器的有用信息。通过它，我们可以检索操作系统、使用的Web服务器、服务器的运行时间、Netblock属主、与Web服务器和操作系统有关系的修改记录等信息。例如：
 |
| 图4 |
五、小结
当我们进行安全渗透测试的时候，首先要做的就是尽可能多地收集目标应用程序信息，所以，信息搜集是渗透测试一个必不可少的步骤。本文为读者介绍了如何测试robots.txt文件、利用搜索引擎进行搜集有用信息以及识别应用程序入口的方法。在本文的下篇中，我们将为读者详细介绍如何测试目标地址上运行了哪些应用程序，以及如何通过错误信息提前有用消息的具体方法。
通过使用搜索引擎、扫描器、发送简单的HTTP请求或者专门精心制作的请求，都有可能导致应用程序泄漏诸如错误信息、版本信息以及所使用的技术等信息。本文将为读者详细介绍如何测试目标地址上运行了哪些应用程序，以及如何通过错误信息提前有用消息的具体方法。
一、识别应用程序
测试Web应用程序漏洞时，最重要的一步就是要弄清楚Web服务器上托管了哪些应用程序。许多应用程序都有已知的漏洞和攻击方法，籍此可以获得远距控制权或获得机密数据。 此外，许多应用程序经常出现配置错误，或者长期不更新，因为有些人总觉得它们是在“内部”使用的，所以就掉以轻心了。
过去，Web服务器和IP地址的关系通常是一比一的，但是随着虚拟Web服务器的快速增长，许多网站/应用程序都共享同一个IP地址。
作为安全专业人员，有时候为测试一个目标服务器需要处理一组IP地址。问题是，若给定的IP地址实在80端口托管了一个HTTP服务的话，那么当您通过规定IP地址来访问该服务时，它会报告该地址没有配置Web服务器之类的消息。实际上，系统可能“隐藏”了许多Web应用程序，只是它们被赋予了一些无关的符号名称而已。显然，分析的广度受被测应用程序的影响较大，您可能没有注意到它们，或者只注意到了其中的一部分。有时候，需要测试的目标对象很多，如一列IP地址和它们对应的符号名称。虽然如此，这个列表可能仅仅传递了部分信息,即它可能遗漏了一些符号名称——因为即使客户也不知道它们，尤其是对于那些大型组织。
影响审计范围的其他问题是非显式、没有从任何地方引用它们的URL(例如http://www.example.com/some-strange-URL)公布的Web应用程序。这可能是由于错误配置所致，也可能是故意所为，比如，非公开的管理接口。为了解决这个问题，需要进行web应用程序探测。
下面介绍黑盒子测试及实例。Web应用程序探测是一个寻找给定基础设施上的Web应用程序的过程。这些基础设施通常是用一组IP地址来规定的，或者也可以使用一组DNS符号名称给出，或者两者兼而有之。无论是典型的渗透测试或者以应用程序为中心的评估测试，这些信息都需要在实际进行审计之前给出。除非聘用合同另文专述(例如 “仅仅针对地址为http://www.example.com/上的应用程序进行测试”)，否则审计应当尽量展开，,那就是说它应该找出通过给定目标可访问的所有的应用程序。在下面的例子中，我们将研究一些可以实现上述目标的技术。
注意：后面介绍的一些技术适用于面向Internet的Web服务器、DNS和基于Web的反向IP解析服务和搜索引擎。在示例中，我们使用私人IP地址(诸如192.168.1.100)表示通用IP地址。
有三个因素影响到与一个给定DNS名称(或者一个IP地址)有关的应用程序的数量：
1. 不同的基URL
对于一个Web应用程序来说，一个显而易见的入口点就是http://www.example.com/，但是并不是强制要求Web应用程序必须从“/”开始，比如，相同的符号名称可以赋给三个不同的Web应用程序：http://www.example.com/url1、http://www.example.com/url2和http://www.example.com/url3。在这个例子中，http://www.example.com/这个URL没有联系到一个具体的应用程序；此外，除非我们明确了解如何找到它们，即我们知道url1、url2、url3，否则这三个应用程序就是“隐身的”。但是，通常情况下我们无需通过这种隐身方式公布Web应用程序，除非您不想以标准方式供人们访问，而是秘密通知您的用户这些应用程序的具体位置。尽管如此，这并不意味着这些应用程序就是隐蔽的的，只不过没有公布它们的位置而已，实际上它们仍然在那里。
2. 非标准的端口
虽然Web应用程序通常位于80端口（http）和443(https)，但是Web应用程序可以绑定到任意TCP端口，并通过指定端口号来引用它们，如http[s]://www.example.com:port/。比如，For example, http://www.example.com:20000/。
3. 虚拟主机
DNS允许我们把单个IP地址映射到一个或多个符号名称上，比如，IP地址192.168.1.100可以映射到下列DNS名称：names www.example.com、helpdesk.example.com和 webmail.example.com。虚拟主机通常采用这种一对多的方式提供不同的内容。规定我们正在引用的虚拟主机的信息将被嵌入到HTTP 1.1的Host:头部中。
除非我们知道了helpdesk.example.com和webmail.example.com，否则我们不会怀疑还有其他Web应用程序。
下面介绍解决这些问题的方法：
解决问题1的方法
实际上，我们没有办法彻底地找出所有采用非标准命名的Web应用程序。因为是非标准的，所以没有固定的标准来指导命名，不过有若干技术可供渗透测试人员用来获得一些额外的洞察力。首先，如果Web服务器的配置出错，允许浏览目录，就有可能找出这些应用程序。安全漏洞扫描器也可以帮我们完成此任务。其次，这些应用程序可以通过其他web页面来引用；所以，它们可以已经被网络蜘蛛爬到，或者已经被搜索引擎索引。如果我们怀疑在www.example.com上存在这样的隐身应用程序，我们就可以使用站点操作符用google搜索，然后使用“site: www.example.com”检查搜索结果。 返回的URL中可能有指向这些非显式的应用程序的。另一种方法是考察那些看起来很像是非公开应用程序的URL。 比如，一个Web邮件前端可以通过诸如https://www.example.com/webmail、https://webmail.example.com/或https://mail.example.com/之类的URL访问。 对于管理接口(比如，一个Tomcat管理接口)，也许可通过隐藏URL中，但是却没有被任何其他地方引用。所以，进行字典式搜索也许会有所收获。 安全漏洞扫描器在这方面也很有用。
解决问题2的方法
检查非标准的端口上的Web应用程序相对来说较为容易。例如，可以使用端口扫描程序，如nmap，加上-sV选项来识别任意端口上的服务，包括http[s]服务。对于64k的TCP 端口地址空间进行全面的扫描是很有必要的。比如，以下命令将查寻IP地址为192.168.1.100的所有开放端口，并设法确定出其上捆绑了哪些服务：
nmap –PN –sT –sV –p0-65535 192.168.1.100 |
通过检查输出并找出http或者SSL封装的服务标志即可。比如，前面的命令的输出结果如下所示：
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 Web接口。
◆在端口1241上的服务并非https，而是用SSL封装过的Nessus守护进程。
◆端口3690运行了一个未详细说明的服务。
◆另外一种未详细说明的服务位于端口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 ... |
这就表明，它实际上是一个HTTP服务器。此外，我们还可以利用一个Web浏览器访问这个URL，或者使用Perl的GET或者HEAD命令来加以验证。
端口8080上运行了Apache Tomcat。
当然了，这个任务也可以通过安全漏洞扫描器完成，但前提是你的扫描器能识别运行于非标准的端口上的http[s]服务。比如，Nessus能够识别任意端口上的http[s]服务，并能对已知的Web服务器漏洞进行测试，同时还能对https服务的SSL 配置进行测试。就像之前暗示的一样，Nessus还能认出流行的应用程序/Web接口，比如，Tomcat的管理接口。
解决问题3的方法
要弄清指定IP地址有关的DNS名称有多种方法可用。第一种方法是DNS区域传送法。域名服务器DNS(Domain Name Service)中保存了域内的主机名和IP地址的对应关系列表。“zone transfer”命令可以使DNS服务器返回域内所有域名的列表，所以DNS Zone Transfer可被用来发现域内的主机和路由器。这种技术现在已经被限制使用，因为DNS服务器已经不太接受分区传输。不过，它仍然值得一试。首先我们必须确定解析给定IP地址的DNS服务器。如果给定地址x.y.z.t的符号名称是已知的，如www.example.com ，那么可以通过诸如nslookup、host或者dig之类的工具来确定出相应的名字服务器。如果不知道给定地址的符号名称，但是测试目标中至少包含一个符号名称，那么可以设法查询那个名称的名字服务器，因为给定地址使用的名字服务器使用的也是这个名字服务器。比如，如果你的审计对象中包含IP地址x.y.z.t和名字mail.example.com，就能找出用于example.com域的名字服务器。
下面的示例展示了如何识别用于www.owasp.org的名字服务器，使用的host命令如下所示：
$ 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和不太明显的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反向查询法。这个过程与前面的非常类似，但是要依赖于逆向DNS记录。与请求一个区域传输不同的是，将记录类型设置为PTR，并查询给定的IP地址。如果运气不错的话，会返回一个DNS名字项。这种技术完全依赖于是否存在IP到符号名称的映射，但是这种映射并不是总存在。
第三种方法是基于Web的DNS搜索法。这种搜索类似DNS区域传输，但是前者完全依赖于基于Web的服务，这种服务的一个例子就是Netcraft的DNS搜索服务，地址http://searchdns.netcraft.com/?host。您可以在此查询隶属于选定域名诸如example.com的一列名称。然后就可以检查获得的名称是否与审计的对象相关。
第四种方法是反向IP服务。反向IP服务（查看某IP 地址下共享哪些域名）或称IP反查，类似于DNS反向查询，区别就是查询的是一个基于 Web 的应用程序而不是名字服务器。现在有许多这样的服务可用。因为它们返回的结果可能有所偏差，所以最好使用多个服务以便进行综合分析。下面给出一些地址：
Domain tools reverse IP: http://www.domaintools.com/reverse-ip/ (需要免费注册)
MSN search: http://search.msn.com 语法： "ip:x.x.x.x" (没有引号)
Webhosting info: http://whois.webhosting.info/ 语法： http://whois.webhosting.info/x.x.x.x
DNSstuff: http://www.dnsstuff.com/ (有多种服务可用)
tomDNS: http://www.tomdns.net/ (一些服务仍然是非公开的)
SEOlogs.com: http://www.seologs.com/ip-domains.html (反向IP/域名查找)
第五种方法是使用搜索引擎。采用前面的技术搜集信息之后，您可以通过搜索引擎来协助分析。这可以进一步考察额外的符号名称是否是可通过非明显的URL访问的审计目标或者应用程序。举例来说，还是以前面www.owasp.org为例，您可以通过Google及其他搜索引擎进行搜索，来查找与新发现的域名webgoat.org、webscarab.com和webscarab.net有关的信息。使用搜索引擎的技术已经在前面介绍过了。
二、测试错误代码
我们对Web应用程序进行渗透测试时，通常会遇到许多应用程序或者Web服务器生成的错误代码。要想显示这些代码的话，需要使用一些特殊的请求，或者专门精心制作的工具。 这些代码对于渗透测试人员而言非常有用，因为它们揭示了数据库、缺陷及其他与Web应用程序直接链接的组件的大量信息。本节将分析一些常见的错误信息代码如何用于漏洞评估。在进行信息搜集时，要特别注意这些错误代码，因为它们对于下一步的工作帮助很大——提高工作效率，降低测试总用时。
在搜索期间一个常见的错误就是HTTP 404 Not Found。通常情况下，该代码会提供底层Web服务器和相关组件的详细信息。举例来说:
Not Found The requested URL /page.html was not found on this server. Apache/2.2.3 (Unix) mod_ssl/2.2.3 OpenSSL/0.9.7g DAV/2 PHP/5.1.2 Server at localhost Port 80 |
这个错误消息可能是在请求一个不存在的URL的时候产生的，它会提供Web服务器版本、操作系统、模块及其他相关产品等有用信息。当我们调查操作系统和应用类型的类型和版本的时候，这些信息是十分重要的。
在进行安全审计时，Web服务器不仅会返回有用的错误信息，例如可以考虑一下如下所示的出错信息例子：
Microsoft OLE DB Provider for ODBC Drivers (0x80004005) [DBNETLIB][ConnectionOpen(Connect())] - SQL server does not exist or access denied |
怎么回事？别急，我们下面一步一步的加以介绍。在本例中，80004005是一个IIS错误代码，表示无法设立连接至相关数据库的连接。很多情况下，这个出错信息会给出数据库类型的详细信息。它通常会给出底层使用的操作系统，藉由该信息，渗透测试人员也可以规划相应的策略。
通过控制传给数据库连接串的变量，我们可以得到更详尽的错误代码。
Microsoft OLE DB Provider for ODBC Drivers error '80004005' [Microsoft][ODBC Access 97 ODBC driver Driver]General error Unable to open registry key 'DriverId' |
在本例中，我们可以看到一个常见的误差，它暴露出有关数据库系统的类型和版本，以及所依赖的Windows 操作系统的注册表项值。
现在，我们考察一个实际的例子，测试一个连接数据库服务器失败并且没有正确处理异常的Web应用程序。这可能导致数据库名称解析问题，处理非预期的变量值或者其他网络问题。
设我们具有一个管理数据库的web接口，它被用作一个前端GUI来发送数据库查询、创建表以及修改数据库字段等。在发送包含登录证书的POST请求期间，渗透测试人员会收到以下错误信息。这则消息表明存在一个MySQL数据库服务器：
Microsoft OLE DB Provider for ODBC Drivers (0x80004005) [MySQL][ODBC 3.51 Driver]Unknown MySQL server host |
如果我们发现登录页面的HTML代码存在数据库IP的隐式字段的话，我们就可以尝试在带有数据库服务器地址的URL中设法改变这个值，以便让应用程序误认为登录成功。
另外一个例子是，如果知道Web应用程序使用的数据库服务器，我们可以利用该信息对这个服务器进行SQL注入攻击测试或者持久性XSS测试。
IIS和ASP.net中的错误处理
ASP .net是微软公司用于开发Web应用程序的框架；IIS是常用的Web服务器之一。 对于应用程序的错误，我们应设法多收集，但是要想覆盖每一个异常是不可能的。
IIS使用一组定制的错误页面（通常位于c:\winnt\help\iishelp\common下面）来向用户显示类似“404page not found”之类的错误。这些默认的页面可以进行修改，并且可以为IIS服务器配置定制的错误消息。 当IIS收到一个aspx页面的请求的时候，就会将其传递给.net 框架.
在.net框架中，处理这些错误的方法有多种。在ASP .net中，可以在三处处理这些错误：
1.在Web.config customErrors部分中
2.在global.asax Application_Error Sub中
3.在Page_Error sub中的aspx或者相关codebehind页面
使用web.config处理错误
|
|
如果mode="On"，则开启定制的错误功能；如果mode=RemoteOnly，将向远程Web应用程序用户展示定制的错误。从本地访问服务器的用户将看到完整的堆栈跟踪，但是无法显示定制的错误。
所有的错误会导致一个重定向，也就是说被重定向到defaultRedirect（例如myerrorpagedefault）指定的资源。状态码404将由myerrorpagefor404.aspx进行处理。
在Global.asax中处理错误
当发生错误的时候，就会调用Application_Error，所以开发人员可以在此编写用于错误处理/页面重定向代码。
Private Sub Application_Error (ByVal sender As Object, ByVal e As System.EventArgs) End Sub |
在Page_Error sub中处理错误信息
这与应用程序错误非常类似：
Private Sub Page_Error (ByVal sender As Object, ByVal e As System.EventArgs) End Sub |
在ASP .net中的错误层次结构
首先，处理Page_Error sub，然后是global.asax的Application_Error sub，最后是web.config文件中的customErrors部分。
在对带有服务器端技术的Web应用程序进行信息搜集是很困难的，不过发现的信息对正确执行下一步的测试十分有用，例如接下来要使用sql注入攻击或者跨站脚本攻击攻击进行测试等，同时还能降低误报率。
如何对ASP.net和IIS的错误处理进行测试
启动浏览器然后输入一个随机的页面名称：
http:\\www.mywebserver.com\anyrandomname.asp
如果服务器返回下列内容：
The page cannot be found HTTP 404 - File not found Internet Information Services |
这表明，IIS没有配置定制的错误功能。请注意扩展名.asp，还要针对.net定制的错误进行测试：在浏览器中输入一个随机的页面名称，只要扩展名为aspx即可：
http:\\www.mywebserver.com\anyrandomname.aspx
如果服务器返回下列内容：
Server Error in '/' Application. -------------------------------------------------------------------------------- The resource cannot be found. Description: HTTP 404. The resource you are looking for (or one of its dependencies) could have been removed, had its name changed, or is temporarily unavailable. Please review the following URL and make sure that it is spelled correctly. |
这说明没有为.net配置定制的错误消息。
下面我们介绍相应的黑盒子测试及实例：
测试方法：
telnet GET / |
返回的结果：
HTTP/1.1 404 Not Found Date: Sat, 04 Nov 2006 15:26:48 GMT Server: Apache/2.2.3 (Unix) mod_ssl/2.2.3 OpenSSL/0.9.7g Content-Length: 310 Connection: close Content-Type: text/html; charset=iso-8859-1 |
测试方法：
1. 网络问题
2. 有关主机数据库地址的不当配置
返回的结果：
Microsoft OLE DB Provider for ODBC Drivers (0x80004005) ' [MySQL][ODBC 3.51 Driver]Unknown MySQL server host |
三、小结
当我们进行安全渗透测试的时候，首先要做的就是尽可能多地收集目标应用程序信息，所以，信息搜集是渗透测试一个必不可少的步骤。本文详细介绍了如何测试目标地址上运行了哪些应用程序，以及如何通过错误信息提前有用消息的具体方法。
