一、识别应用程序
测试Web应用程序漏洞时，最重要的一步就是要弄清楚Web服务器上托管了哪些应用程序。许多应用程序都有已知的漏洞和攻击方法，籍此可以获得远距控制权或获得机密数据。 此外，许多应用程序经常出现配置错误，或者长期不更新，因为有些人总觉得它们是在“内部”使用的，所以就掉以轻心了。
影响审计范围的其他问题是非显式、没有从任何地方引用它们的URL(例如)公布的Web应用程序。这可能是由于错误配置所致，也可能是故意所为，比如，非公开的管理接口。为了解决这个问题，需要进行web应用程序探测。
1. 不同的基URL
对于一个Web应用程序来说，一个显而易见的入口点就是，但是并不是强制要求Web应用程序必须从“/”开始，比如，相同的符号名称可以赋给三个不同的Web应用程序：、和。在这个例子中，这个URL没有联系到一个具体的应用程序；此外，除非我们明确了解如何找到它们，即我们知道url1、url2、url3，否则这三个应用程序就是“隐身的”。但是，通常情况下我们无需通过这种隐身方式公布Web应用程序，除非您不想以标准方式供人们访问，而是秘密通知您的用户这些应用程序的具体位置。尽管如此，这并不意味着这些应用程序就是隐蔽的的，只不过没有公布它们的位置而已，实际上它们仍然在那里。
2. 非标准的端口
虽然Web应用程序通常位于80端口（http）和443(https)，但是Web应用程序可以绑定到任意TCP端口，并通过指定端口号来引用它们，如http[s]://www.example.com:port/。比如，For example, 。
3. 虚拟主机
除非我们知道了helpdesk.example.com和webmail.example.com，否则我们不会怀疑还有其他Web应用程序。
下面介绍解决这些问题的方法：
解决问题1的方法
解决问题2的方法
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服务器，我们还需进一步确认，例如利用一个浏览器访问即可揭晓。
◆在端口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的方法
下面的示例展示了如何识别用于的名字服务器，使用的host命令如下所示：
$ host -t ns is an alias for owasp.org. owasp.org name server ns1.secure.net. owasp.org name server ns2.secure.net. |
可以向解析example.com的名字服务器发送区域传输请求。如果运气好的话，就会得到用于该域名的一列DNS条目。其中包含显而易见的和不太明显的webmail.example.com等。 仔细考察区域传输返回的所有名称，并思考那些与审计对象有关。
可以尝试请求用于owasp.org的区域传输：
$ host -l ns1.secure.net Using domain server: Name: ns1.secure.net Address: 192.220.124.10#53 Aliases: Host not found: 5(REFUSED) ; Transfer failed. |
Domain tools reverse IP: (需要免费注册)
MSN search: 语法： "ip:x.x.x.x" (没有引号)
Webhosting info: 语法：
DNSstuff: (有多种服务可用)
(要求安装)
tomDNS: (一些服务仍然是非公开的)
SEOlogs.com: (反向IP/域名查找)
第五种方法是使用搜索引擎。采用前面的技术搜集信息之后，您可以通过搜索引擎来协助分析。这可以进一步考察额外的符号名称是否是可通过非明显的URL访问的审计目标或者应用程序。举例来说，还是以前面为例，您可以通过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 |
另外一个例子是，如果知道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 80 GET / HTTP/1.1 |
返回的结果：
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. 网络问题
返回的结果：
Microsoft OLE DB Provider for ODBC Drivers (0x80004005) ' [MySQL][ODBC 3.51 Driver]Unknown MySQL server host |
三、小结