【51CTO.com獨家特稿】當我們進行安全滲透測試的時候，首先要做的就是盡可能多地收集目標應用程序信息，所以，信息搜集是滲透測試一個必不可少的步驟。這項任務可以通過多種不同的方式來完成，

通過使用搜索引擎、掃描器、發送簡單的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應用程序。 #p#

下面介紹解決這些問題的方法：

解決問題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/ (有多種服務可用)

http://net-square.com/msnpawn/index.shtml (要求安裝)

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) 
     
Handles MyBase.Error

End Sub

在Page_Error sub中處理錯誤信息

這與應用程序錯誤非常類似：

Private Sub Page_Error (ByVal sender As Object, ByVal e As System.EventArgs) 
    
Handles MyBase.Error

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. 網絡問題

2. 有關主機數據庫地址的不當配置

返回的結果：

Microsoft OLE DB Provider for ODBC Drivers (0x80004005) '

[MySQL][ODBC 3.51 Driver]Unknown MySQL server host

三、小結

當我們進行安全滲透測試的時候，首先要做的就是盡可能多地收集目標應用程序信息，所以，信息搜集是滲透測試一個必不可少的步驟。本文詳細介紹了如何測試目標地址上運行了哪些應用程序，以及如何通過錯誤信息提前有用消息的具體方法。

【51CTO.COM 獨家特稿，轉載請注明出處及作者！】