2019測試指南-web應用程序安全測試（二）在Web服務器上枚舉應用程序

時間 2019-11-09

標籤測試指南 web 應用程序安全服務器枚舉欄目 HTML 简体版

原文原文鏈接

測試Web應用程序漏洞的最重要步驟是找出Web服務器上託管的特定應用程序。許多應用程序都具備已知的漏洞和已知的攻擊策略，能夠利用這些策略來獲取遠程控制或利用數據。此外，許多應用程序常常被錯誤配置或未更新，由於他們認爲它們僅在「內部」使用，所以不存在威脅。php

隨着虛擬Web服務器的普及，IP地址和Web服務器之間傳統的1：1類型關係正在失去其原有的重要意義。擁有符號名稱解析爲同一IP地址的多個網站或應用程序並不罕見。此方案不只限於託管環境，也適用於普通的企業環境。html

安全專業人員有時會得到一組IP地址做爲測試目標。能夠說這種狀況更相似於滲透測試類型的參與，但不管如何，預計這樣的任務將測試經過該目標可訪問的全部Web應用程序。問題是給定的IP地址在端口80上託管HTTP服務，可是若是測試人員應該經過指定IP地址（他們都知道）來訪問它，它會報告「沒有在此地址配置的Web服務器」或相似的消息。可是該系統能夠「隱藏」許多與不相關的符號（DNS）名稱相關聯的Web應用程序。顯然，分析的程度深受測試人員測試全部應用程序或僅測試他們知道的應用程序的影響。前端

有時，目標規範更豐富。能夠給測試者一個IP地址列表及其相應的符號名稱。然而，這個列表可能會傳達部分信息，即它可能會省略一些符號名稱，而客戶可能甚至都沒有意識到這一點（這種狀況更有可能發生在大型組織中）。web

影響評估範圍的其餘問題由在非顯而易見的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地址。已經揭示了映射到同一地址的另外三個非顯而易見的符號名稱。