2019測試指南-web應用程序安全測試（二）地圖應用架構

時間 2019-11-13

標籤測試指南 web 應用程序安全地圖架構欄目 HTML 简体版

原文原文鏈接

互連和異構Web服務器基礎架構的複雜性可包括數百個Web應用程序，並使配置管理和審查成爲測試和部署每一個應用程序的基本步驟。實際上，只須要一個漏洞就能夠破壞整個基礎架構的安全性，即便是一些看似不重要的小問題也可能會演變成同一臺服務器上另外一個應用程序的嚴重風險。html

要解決這些問題，最重要的是對配置和已知安全問題進行深刻審查。在進行深刻審查以前，有必要映射網絡和應用程序架構。須要肯定構成基礎架構的不一樣元素，以瞭解它們如何與Web應用程序交互以及它們如何影響安全性。前端

如何測試

映射應用程序架構

須要經過一些測試來映射應用程序體系結構，以肯定用於構建Web應用程序的不一樣組件。在小型設置中，例如簡單的基於CGI的應用程序，可能使用單個服務器來運行執行C，Perl或Shell CGI應用程序的Web服務器，也可能使用身份驗證機制。web

在更復雜的設置上，例如在線銀行系統，可能涉及多個服務器。這些可能包括反向代理，前端Web服務器，應用程序服務器和數據庫服務器或LDAP服務器。這些服務器中的每個都將用於不一樣的目的，甚至可能分爲不一樣的網絡，它們之間有防火牆。這將建立不一樣的DMZ，以便對Web服務器的訪問不會授予遠程用戶對身份驗證機制的訪問權限，從而能夠隔離對體系結構的不一樣元素的妥協，以便它們不會危及整個體系結構。算法

若是應用程序開發人員以文檔形式或訪談方式向測試團隊提供此類信息，則能夠輕鬆獲取應用程序體系結構的知識，但若是進行盲目滲透測試，也可能會很是困難。數據庫

在後一種狀況下，測試人員首先假設存在簡單的設置（單個服務器）。而後，他們將從其餘測試中檢索信息並導出不一樣的元素，質疑這個假設並擴展架構圖。測試人員將首先提出簡單的問題，例如：「是否存在保護Web服務器的防火牆系統？」。將根據針對Web服務器的網絡掃描結果以及是否在網絡邊緣過濾Web服務器的網絡端口（未收到應答或ICMP不可訪問）或服務器是否爲直接鏈接到Internet（即返回全部非偵聽端口的RST數據包）。能夠加強此分析以肯定基於網絡數據包測試使用的防火牆類型。它是狀態防火牆仍是路由器上的訪問列表過濾器？它是如何配置的？能夠繞過嗎？後端

在Web服務器前檢測反向代理須要經過分析Web服務器標題來完成，這可能直接披露反向代理的存在（例如，若是返回'WebSEAL'[1]）。它還能夠經過獲取Web服務器給出的請求並將它們與預期答案進行比較來肯定。例如，一些反向代理經過阻止針對Web服務器的已知攻擊來充當「入侵防護系統」（或網絡屏蔽）。若是已知Web服務器使用404消息回答針對不可用頁面的請求，並針對某些常見Web攻擊（如CGI掃描程序所執行的那些）返回不一樣的錯誤消息，它可能表示反向代理（或應用程序級防火牆）正在過濾請求並返回與預期不一樣的錯誤頁面。另外一個例子：若是Web服務器返回一組可用的HTTP方法（包括TRACE），但預期的方法返回錯誤，那麼阻塞它們之間可能存在一些問題。緩存

在某些狀況下，甚至保護系統都會讓本身離開：安全

GET /web-console/ServerInfo.jsp%00 HTTP / 1.0 HTTP / 1.0 200 Pragma：沒有緩存 緩存控制：無緩存 內容類型：text / html 內容長度：83 <TITLE>錯誤</ TITLE> <BODY> <H1>錯誤</ H1> XXXXXX的FW-1：拒絕訪問。</ BODY>

Check Point Firewall-1 NG AI的安全服務器示例「保護」Web服務器服務器

反向代理也能夠做爲代理緩存引入，以加速後端應用程序服務器的性能。能夠基於服務器頭來完成檢測這些代理。它們也能夠經過服務器應該緩存的計時請求來檢測，並將服務第一個請求所花費的時間與後續請求進行比較。cookie

能夠檢測的另外一個元素是網絡負載平衡器。一般，這些系統將基於不一樣的算法（循環，Web服務器負載，請求數量等）將給定的TCP / IP端口平衡到多個服務器。所以，須要經過檢查多個請求並比較結果以肯定請求是否轉到相同或不一樣的Web服務器來完成對該體系結構元素的檢測。例如，若是服務器時鐘未同步，則基於Date標頭。在某些狀況下，網絡負載平衡過程可能會在標題中注入新信息，使其不同凡響，例如Nortel的Alteon WebSystems負載均衡器引入的AlteonP cookie。

應用程序Web服務器一般很容易檢測到。對多個資源的請求由應用程序服務器自己（而不是Web服務器）處理，響應頭將顯着變化（包括答案頭中的不一樣或附加值）。另外一種檢測方法是查看Web服務器是否嘗試設置指示正在使用的應用程序Web服務器的cookie（例如某些J2EE服務器提供的JSESSIONID），或者自動重寫URL以進行會話跟蹤。

然而，身份驗證後端（例如LDAP目錄，關係數據庫或RADIUS服務器）不容易從外部角度以直接方式檢測，由於它們將被應用程序自己隱藏。

能夠經過導航應用程序簡單地肯定後端數據庫的使用。若是「動態」生成高度動態的內容，則多是應用程序自己從某種數據庫中提取的。有時，請求信息的方式可能會讓人瞭解數據庫後端的存在。例如，在瀏覽商店中的不一樣文章時使用數字標識符（'id'）的在線購物應用程序。可是，在進行盲應用程序測試時，一般只有在應用程序中出現漏洞時才能得到底層數據庫的知識，例如糟糕的異常處理或對SQL注入的敏感性。