避開客戶端控件的滲透測試方法

                           

一．經過客戶端傳送數據

1.1 隱藏表單字段

  隱藏HTML表單字段是一種以表面看似沒法修改的方式經過客戶傳送數據的經常使用機制。若是一個表單標記爲隱藏，那麼它就不會顯示在屏幕上。可是，當用戶提交表單時，保存在表單中的字段名稱和值被送給應用程序。

在隱藏表單字段中保存產品價格的零售應用程序就是存在這種安全缺陷的典型示例。在Web應用程序發展的早期階段，這種漏洞及其廣泛，如今也絕沒有消失。

雖然Price字段未顯示在屏幕上，而且用戶沒法對其進行編輯，但這只是由於應用程序指示瀏覽器隱藏該字段而已。由於在客戶端進行的一切操做最終將由用戶控制，用戶編輯這個字段時可解除這個限制。要實現編輯操做，一種方法是保存HTML頁面的源代碼，編輯字段的值，而後將源代碼從新載入瀏覽器，並單擊Buy按鈕。然而，使用攔截代理服務器對數據進行動態修改更加簡單方便。

當攻擊Web應用程序時，攔截代理服務器及其有用，他是一種不可缺乏的工具。咱們能夠找到大量攔截代理服務器工具，但以這些工具功能最強大，使用最廣泛：

1.Burp Proxy（Burp 套件的一個組件）

2.WebScarab

3.Paros

 

代理服務器位於Web瀏覽器和目標應用程序之間。它攔截應用程序發佈和收到的每個HTTP或HTTPS請求和響應。

 

1.2 Referer消息頭

瀏覽器在大多數HTTP請求中使用Referer消息頭。瀏覽器使用這個消息頭說明提出當前請求頁面的URL。

滲透測試步驟：

1.再應用程序中，肯定隱藏表單字段、cookie和URL參數明顯被用於經過客戶傳送數據的任何狀況。

2.根據數據出現的位置及參數名稱之類的線索，肯定或猜想它在應用程序邏輯中發揮的做用

3.修改數據在應用程序相關功能中的值。肯定應用程序是否處理參數提交的任意值，以及這樣作是否使應用程序易於遭受某種攻擊。

 

1.3 模糊數據

滲透測試步驟：

可使用如下幾種方法對經過客戶傳送的模糊數據實施攻擊。

1.若是知道模糊字符串的明文值，就能夠嘗試破譯模糊處理所使用的模糊算法

2.如第四章所述，應用程序的其餘地方可能包含一些功能，能夠利用他們返回由其控制的一段明文生成的模糊字符串。在這種狀況下，能夠向攻擊的功能直接提交任意一個有效載荷，得到所須要的字符串

3.即便模糊字符串徹底沒法理解，也能夠在其餘狀況下從新傳送它的值。實現某種惡意效果。例如，前面的表單的enc參數中可能包含一個加密的產品價格。儘管沒法對所選擇的任意價格以相同的算法進行加密，可是能夠把另外一個更便宜的產品的加密價格複製過來，放在這裏提交。

4.若是其餘全部方法所有無效，仍是能夠經過提交畸形字符串（如包含超長值，不一樣字符集錯誤的字符串）設法對模糊數據進行解密或飯模糊處理的服務器端邏輯實施攻擊。

 

1.4 ASP.NET ViewState

ASP.NET ViewState是一種經過客戶傳送模糊數據的經常使用機制。它是一種在全部ASP.NETWeb應用程序中默認創建的隱藏字段，其中包含關於當前頁面狀態的序列化信息。

ViewState參數其實是一個可被輕易解碼的Base64編碼字符串。當對一個明顯的Base64編碼字符串進行解碼時，經常會範一個錯誤，即從字符串的錯誤位置開始解碼。鑑於Base64編碼的特色，若是從錯誤的位置開始解碼，解碼後的字符串中將出現亂碼。Base64採用一種塊格式，每4個字節的編碼數據解碼後將變爲3個字節，所以，若是解碼後的Base64字符串毫無心義，請嘗試從編碼字符串的4個相鄰的偏移值（offset）位置開始解碼。

滲透測試步驟：

1.滲透測試員在攻擊ASP.NET應用程序時，須要先肯定EnableViewStateMac選項是否被激活。若是ViewState結構末尾存在一個20字節的散列，即表示應用程序激活了該選項，可使用Burp Proxy中的解碼器肯定上述散列是否存在。

2.即便ViewState受到保護，仍是能夠解碼各類不一樣應用程序頁面中的ViewState參數，瞭解應用程序是否使用ViewState經過客戶傳送任何敏感數據。

3.試着修改ViewState中某個特殊參數的值，但不破壞它的結構，看看是否會致使錯誤消息。

4.若是可以修改ViewState而不會形成錯誤，應該分析ViewState中每一個參數的功能，並分析應用程序是否使用它保護任何定製數據。嘗試用專門設計的值代替每個參數，探查常見的漏洞，就像檢查經過客戶傳送的其餘數據項同樣。

5.注意，每一個頁面可能激活或禁用密鑰散列選項，所以有必要測試應用程序的每個重要頁面，瞭解其中是否存在ViewState攻擊漏洞。

 

二．收集用戶數據：HTML表單

2.1 長度限制

滲透測試步驟：

1.尋找包含maxlength屬性的表單元素。提交大於這個長度但其餘格式合法的數據（即若是這個程序要求數字，就提交一個數值）

2.若是應用程序接受這個超長的數據，可據此判斷出服務器並無採用客戶端確認機制。

3.根據應用程序隨後對參數進行的處理，能夠經過確認機制中存在的缺陷利用其餘漏洞（如SQL注入、跨站點腳本或緩存區溢出）

 

2.2 基於腳本的確認

滲透測試步驟：

1.肯定任何在提交表單前使用客戶端JavaScript進行輸入確認的狀況

2.經過修改被提交的請求，在其中插入無效數據；或者修改確認代碼使其失效，向服務器提交確認機制一般會阻止的數據

3.與長度同樣，肯定服務器是否採用了和客戶端相同的控件，若是並不是如此，肯定是否可利用這種狀況實現任何惡意意圖。

4.注意，若是在提交表單前有幾個輸入字符須要由客戶端確認機制檢驗，須要分別用無效數據測試每個字段，同時在全部其餘字段中使用有效數據。若是同時在幾個字段中提交無效數據，可能服務器在識別出第一個無效字段時就已經中止執行表單，於是使測試沒法到達應用程序的全部可能代碼路徑。

 

使用客戶端JavaScript程序確認用戶輸入的作法在Web應用程序中很是廣泛，但這並不表示這種應用程序全都易於遭受攻擊。只有當服務器並未採用和客戶端相同的確認機制，以及可以避開客戶端確認的專門設計的輸入可用於在應用程序中形成某種沒法預料的行爲時，應用程序才存在風險。

在絕大多數狀況下，在客戶端確認用戶輸入有助於提升應用程序的性能，改善用戶體驗。例如，當填寫詳細的註冊表單時，廣泛用戶可能會犯許多錯誤，如忽略必要的字段或電話號碼格式出現的錯誤。若是不採用客戶端確認機制，更正這些錯誤可能須要屢次提交註冊頁面，反而向服務器傳送消息。在客戶端執行基本的確認檢查可以使用戶得到更佳的使用體驗，減輕服務器的負擔。

 

2.3 禁用的元素

示例代碼：

<form action = " " method = "post">

<p>Product:<input disabled = "true" name = "product" value = "1234567"></p>

<p>Quantity:<input size = "2" name = "quantity">

<input name = "price" type = "inputbox" value = "1224.95">

<input type = "submit" value = "Buy!"></p>

</form>

 

這個表單的行爲與本章開頭的示例徹底相同：它只提交quantity和price參數。可是，存在禁用字段表示應用程序可能已經使用了這個參數。先前的表單種可能已經含有一個包含產品名稱的隱藏字段或可編輯。這個表單已經提交給服務器並由應用程序處理完成。經過修改產品名稱實施攻擊明顯不如修改其價格有效。可是，若是應用程序處理這個參數，那麼它就易於受到各類攻擊（如SQL注入或跨站點腳本），這正是攻擊者感興趣的。

滲透測試步驟：

1.在應用程序的每個表單中尋找禁用的元素。嘗試將發現的每個元素與表單的其餘參數一塊兒提交給服務器，肯定其是否有效

2.一般，提交元素被標記爲禁用，這些按鈕即以灰色顯示，表示相關操做無效。應該嘗試提交這些參數名稱，肯定應用程序是否在運行被請求的操做前執行服務器端檢查。

3.注意，當提交表單時，瀏覽器中並不包含禁用的表單元素；所以，簡單瀏覽監控由瀏覽器發佈的請求的應用程序功能並不能肯定其中是否含有禁用的元素。要肯定禁用的元素，必須監控服務器的響應或在瀏覽器中查看頁面來源。還可使用攔截代理服務器中的自動「查找與替換」功能，刪除輸入標籤中的禁用屬性。

 

三．收集用戶數據：厚客戶端組件

除HTML表單外，另外一種收集、確認並提交用戶數據的主要方法是使用厚客戶端組件（thick-client component）。最多見的厚客戶端組件包括Java applet、ActiveX控件和Shockwave Flash對象。

厚客戶端組件可經過輸入表單或者在某些狀況下經過與客戶操做系統文件系統或註冊表交互，以各類不一樣的方式收集數據。在收集到數據被提交給服務器以前，他們能夠對其執行任何複雜的確認和處理。並且，因爲他們的內部工做機制與HTML表單和JavaScript相比更加不透明，開發者認爲他們執行的確認更加難以躲避。爲此，經過厚客戶端組件查找Web應用程序中存在的漏洞每每可以得到更大的成果。

不管厚客戶端組件執行何種確認和處理，若是它以「透明」的形式向服務器提交數據，那麼，和上述修改HTML表單數據同樣，使用攔截代理服務器就可對這些數據進行修改。例如，一個支持驗證機制的厚客戶端組件可以獲取用戶證書，對他們進行某種確認，並在請求中以明文參數（plaintext parameter）的形式向服務器提交這些值。然而，攻擊者不須要對組件進行任何分析或實施任何攻擊，就可輕鬆避開這種確認。若是厚客戶端組件首先對收集到的數據進行某種形式的模糊處理，在將他們提交給服務器，那麼厚客戶端組件就成爲一種更加有用，更具挑戰性的目標。在這種狀況下，修改被提交的值將會破壞模糊處理，所以將被服務器拒絕。要避開這種確認，必須對厚客戶端組件進行分析研究，瞭解其執行的確認和模糊處理方法，並以某種方法破壞它的處理機制，從而實現攻擊目的。

 

3.1 Java applet

Java applet之因此成爲一種流行的厚客戶端組件技術，主要在於他們可跨平臺使用，並可以在「沙盒」環境（sandboxed environment）中運行，於是可以避免各類困擾許多「重量級」厚客戶技術的安全問題。

因爲在沙盒中運行，Java applet通常沒法訪問文件系統之類的操做系統資源。所以，他們在客戶控件方面的主要用途，是收集用戶輸入或其它包含在瀏覽器中的信息。

 

一般，Java applet被壓縮成JAR（Java Archive）文件，其中包含各類文件和其餘資源，如聲音和圖像，JAR文件實際上只是帶.jar文件擴展名的ZIP壓縮文件。可使用WinRar或WinZip這些標準文件壓縮工具以及Sun Java SDK中的Jar工具解壓或從新壓縮Jar文件。

分析和處理Java Applet的有用工具還有Jode（一種反編譯器和字節碼模糊處理工具）和JSwat（一種Java調試工具）

 

·3.1.1 反編譯Java字節碼

 

滲透測試步驟：

1.分析應用程序的所有方法調用，肯定由applet返回的數據是否被提交給服務器。

    2.若是數據本質上是「透明的」（即未通過模糊處理或加密），以和處理任何其餘參數同樣的方式探查並攻擊服務器處理提交數據的過程

    3.若是數據屬於模糊數據，反編譯applet以獲取其源代碼

 

4.分析相關源代碼（首先執行返回模糊數據的方法），瞭解它正在執行何種處理

5.肯定applet中是否包含任何可用於對任意輸入執行相關模糊處理的公共方法

6.若是其中沒有這類方法，修改並從新編譯applet的源代碼，以達到令其執行的任何確認失效或容許模糊處理任意輸入的目的。

7.而後，向服務器提交各類通過適當模糊處理的攻擊字符串，以探查其中的漏洞。還應對任何其餘參數進行相同的處理。

 

·3.1.2 字節碼模糊處理

滲透測試步驟：

應對字節碼模糊處理的有效策略取決於分析源代碼使用的技巧和目的。下面是一些建議：

1.沒必要徹底理解源代碼，只需查看applet中是否包含公共方法。哪些方法能夠從JavaScript中調用，它們的標籤是什麼，這些內容應是顯而易見的；能夠經過提交各類輸入測試上述方法的行爲

2.若是已經使用無心義的表達式（並不是Java關鍵字）代替類、方法和成員變量名稱，那麼可使用許多IDE中內置的重構功能幫助理解代碼。經過研究數據的用法，就能夠給它們分配有意義的名稱。IDE中的「重命名」工具能夠幫助完成許多工做：在整個代碼庫中追蹤數據的用法並對每個數據進行重命名

3.選擇適當的選項，在模糊處理工具中再次對模糊處理後的字節碼進行模糊處理，這樣既可撤銷許多模糊處理。Jode是一個實用的模糊處理工具，它可刪除由其餘模糊處理工具添加的多餘代碼路徑，並可爲數據分配惟一的名稱，爲理解模糊處理後的名稱提供幫助。

 

3.2 ActiveX控件

ActiveX控件是一種比Java applet更加「重量級」的技術。它們其實是本地Win32可執行代碼，用戶一旦接受並安裝ActiveX控件，在該用戶的徹底權限下執行時候就可實現任何操做，包括與操做系統交互。

ActiveX可用於執行幾乎任何一種客戶端控制，包括收集用戶輸入和其餘包含在瀏覽器中的信息，並在容許客戶計算機訪問某種功能前，驗證是否知足某些安全標準。

就HTML頁面源代碼而言，ActiveX控件的示例和調用方式與Java applet很是相似。

能夠應用各類技巧解除使用ActiveX執行的客戶端控件。

 

·3.2.1 逆向工程

因爲ActiveX控件通常由C和C++之類的本地語言編寫，所以很難像反編譯Java applet同樣對它進行反編譯，以恢復其源代碼。可是，由於ActiveX控件在客戶計算機上執行所有處理操做，因此，從理論上講，那臺計算機的用戶可以全面檢查並控制它的處理過程，從而避開控件執行的任何安全功能。

滲透測試步驟：

1.避免徹底靜態解析組件代碼，使用一種直觀的GUI調試器監控並管理它在運行時的執行狀況。例如，OllyDbg是一種簡單而強大的調試器，可用於在運行時對編譯型軟件實施各類攻擊。

2.肯定控件及其子組件使用的方法以及控件引入的任何重要的操做系統功能，特別是任何加密功能。在調試器中爲這些功能設置「斷點」

3.若是遇到斷點，分析調用棧，肯定任何被提交給該功能的相關數據，特別是正在接受確認的用戶提交的數據。經過追蹤這些數據的路徑來了解對他們進行的處理。

4.一般，使用調試器可輕易破壞某個進程的執行路徑，使其對攻擊有用。例如，修改棧中做爲輸入提交給某一函數的參數、修改用於傳送函數返回值的EAX寄存器，或者重寫比較和跳轉之類的關鍵指令以改變函數的邏輯。若是可能，使用這些技巧解除確認控件，使函數接受可能爲惡意的數據並對其作進一步處理。

5.若是在其餘處理（如加密或模糊處理）以前執行數據確認，就能夠利用這種多階段的處理方式，向控件提交有效數據，而後攔截並修改已經通過確認的數據。這樣就能夠在將可能的惡意數據提交給服務器端應用程序以前，對其進行適當處理。

6.若是找到一種手動改變控件的處理過程，從而破壞其執行的確認方法，就能夠經過在磁盤上修改控件的二進制代碼（OllyDbg中有一個工具可更新二進制代碼，以反映使用提示器對其進行的更改）或使用Microsoft Detours之類的檢測框架在運行時鏈接目標進程，實現攻擊自動化。

 

·3.2.2 利用輸出函數

滲透測試步驟：

1.開發者一般會用有意義的短語命名ActiveX方法，所以只需經過他們的名稱就可肯定有用的方法。

2.有時候，可使用不一樣的輸入系統的調用一個函數，而後監控該函數的可見行爲，並使用調試器監控器內部工做機制，從而肯定一個函數的用途。