SOAP注入攻擊詳解

在本文中，我們將要對SOAP服務中的一系列安全性漏洞進行測試及利用。並不是所有的攻擊行為都針對SOAP，我們必須對這一情況具備清醒的認識。

這一行的新手往往有種先入為主的觀念，認為威脅網頁服務安全的各類攻擊總帶有一些神秘色彩並且超難阻止。但實際情況是，網頁服務遭受的許多侵襲都源自與瀏覽器應用程式安全缺陷相類似的同一種漏洞。

我們在本文中打算講解並利用的漏洞類型分別為：

1. SOAP 注入

2. SQL 注入

3. 預設內容

4. 破損的認證及會話管理

SOAP 注入

雖然網頁服務方面的許多安全缺陷都有相似之處或者幾乎同樣為福士所熟知，而且這些漏洞不僅被編纂成文供人們參考，甚至要將其真正利用起來也不需要什麼高超的技術。但SOAP注入有所不同，它所指向的弱點不僅難於抵禦，對攻擊者的水平也有相當的要求。

那麼這種攻擊到底是如何發生的？伺服器端的XML解析引擎從用戶端接收輸入資訊，這裡指的用戶端可以是瀏覽器、來自網頁應用程式的資料、一部行動裝置或者是其它類型的來源。如果不對輸入的資訊進行正確驗證，接收的結果就很可能出現錯誤，進而為攻擊行為提供了便利。

基於上述情況，我們就從攻擊者的立場出發，在不具備高超技術或是對SOAP請求伺服器端處理方式的深入瞭解的前提下，一步步接近SOAP注入攻擊的真實流程。這要求我們首先準備一些極度冗長的錯誤資訊（聽起來可能有點像安全配置失誤）。

請遵循下列要求：

請求顯示正常。我們在此發出自己的姓名及密碼，如果請求接下來也同樣發送正常，則解析工作同樣會順利進行。在此，我們能否被授予存取權限取決於初始時提交何種內容的請求。

現在讓我們產生一個同樣的請求，但這一次省略掉

<lname></lname>

 

標籤。

根據顯示的伺服器響應結果可以看出，我們應該是已經取得了某些突破：

這個錯誤警告實際上向我們間接交代出了代碼！我們看到的這條故障提示的實際表意是如果缺少lname變數，那麼代碼應該利用登入ID參數作為替代。現在的事態很有趣。在這種情況下，我們要做的是刻意省略lname標籤以觸發故障提示（"II"），進而提取登入ID標籤。

這是我們建立的新請求：

好了，現在出現的提示資訊如下：

這意味著我們需要利用已經收集到的授權認證或資訊啟動執行操作

(提交

<loginid>1</loginid>

標籤)。

此類攻擊方式相對比較簡單，利用到的是編寫在背景中的、包含錯誤資訊的簡陋解析引擎。如此一來，我們提交的請求就會被作為來自管理員層級賬戶的操作被加以接收。

SQL注入

在這部分內容中，我們將用到在第一部分文章中建立的一些代碼。啟動附有Ruby指令碼的Burp，該指令碼名稱為attack_soap.rb。

讓我們向WSDL檔案發送一條請求，在Burp處實施攔截，產生請求然後將其進行模糊處理及分析。打完收功。

正如第一部分文章中提到的，上述步驟會自動產生一條要求關閉WSDL檔案中操作及參數的SOAP請求。在attack_soap.rb指令碼中，我們已經編寫了特殊的SOAP請求並傳遞至Burp代理。一旦該請求產生並被正確攔截，我們就能將在攻擊中讓其發揮作用。

通過對侵入活動的定位，我們接下來需要編寫打算插入的模糊字串。

請注意，我們對101在插入點中進行了滲透，因此我們的模糊字串將取代整數"101"的位置。

現在要做的是選擇有效荷載。Fuzzdb是模糊字串的上佳來源，我們可以從以下網路中找到任何能在本教程的Burp有效荷載建立方面派上用場的內容：http://code.google.com/p/fuzzdb/。

選擇預設的下拉式清單；在下拉式清單中添加選擇"fuzzing-full"荷載。

開始攻擊，如所示：

現在我們需要審查來自應用程式的響應資訊。請注意，雖然多數的返迴響應都是總長度為634的單位元組內容，但字串"1 or 1=1--"返回的卻是總長度為1662的單位元組內容。

這背後可能有什麼玄機，讓我們拭目以待。

應用程式已經通過回饋信用卡列表的形式響應SQL語句！到此我們利用SOAP服務中的SQL注入漏洞計劃獲得了圓滿成功，掌聲鼓勵。

預設內容尋獲

分析此類漏洞的重點在於提醒各位讀者，正如傳統網頁應用程式的預設內容暴露會引發安全威脅，伺服器託管型網頁服務也具有同樣的特性。

作為攻擊者，大家應該盡最大努力挖掘那些網頁開發人員或管理員忘記刪除的任何隱藏或看似無用的內容。一般來說我們總能發現些沒有經過正確測試或是包含關鍵性漏洞的代碼。此外，這類檔案還可能以某種文字文件或Excel表格形式儲存起來的驗證資訊或其它敏感資源。

通常情況下，我們"至少"應該運行下列Google查詢內容（這些內容並不全面，大家還需要自己加以補充）：

上述查詢所返回的全部檔案都與我們提供的網站名稱相匹配。在大家使用SOAP時，強烈建議各位將添加"filetype:wsdl"作為尋獲網站中額外wsdl檔案的首選方案。

到這一步還不算完。SVNDigger會列出一份龐大的目錄，內容涵蓋各類可以用來尋獲預設內容的目錄及檔案名稱。大家可以在http://www.mavitunasecurity.com/blog/svn-digger-better-lists-for-forced-browsing/處下載這份關鍵詞檢索表，不過我們通過intruder載入模糊列表的形式已經達到了與使用SVNDigger檢索表相同的目的。

大家同樣可以選擇使用OWASP推薦的"DirBuster"工具，並以此種方式載入檢索表。

需要重申的是，暴露在外的預設內容可能會導致由敏感性資料外泄引發的各類嚴重危害。大家在實踐這類攻擊方式時務必謹慎再謹慎，否則可能會帶來災難性的後果。

損壞的驗證及會話管理缺陷

這種類型的漏洞對於網頁服務的影響與對傳統網頁應用程式的影響是相同的。事實上，隨著行動裝置的迅猛崛起，網頁服務也開始對其提供支援。而且我們身邊遭遇此類漏洞威脅的案例也在不斷增加。

每條請求中使用者名稱及密碼的提交

以SOAP請求為例，該請求需要得到上級WSDL的基本授權。這種存在於應用程式及使用者瀏覽器之間的授權標準具備如下互動過程：

1. 使用者提交驗證資訊

2. 應用程式驗證該資訊，並發送一個cookie

3. 使用者瀏覽器儲存來自應用程式的這個cookie值

4. 根據來自使用者瀏覽器的後續請求，該cookie會被再次發往應用程式端

有了這種基本的流程概念，即使那些cookie是竊取來的，在其到期之前應該還是可以奏效一段時間。但如果想要擷取更多資訊以查看或修改密碼，攻擊者只能憑藉自己的運氣。

然而當下太多的行動裝置 App程式利用基本資料驗證與網頁服務進行互動，因此我們常常會發現有些行動裝置 App會在每個發往網頁服務的請求中都夾帶驗證資訊！

如果使用者的手機處於開機狀態並連入允許公開訪問的Wi-Fi網路，而網頁服務使用的又不是HTTPS協議，這就意味著整個傳輸過程利用的負載媒介相當於純文字。讓我們探究一下破解基本驗證資訊到底有多容易。

將基本驗證資訊字串發送至Burp解碼器

正如大家所見，使用者名稱為guest，而密碼也為guest。在這裡我再次強調，行動裝置 App程式中時刻充斥著這類簡單漏洞。

缺乏帳號鎖定機制

輸入一定次數的錯誤口令後，帳號仍未轉為鎖定狀態，這是當前網頁服務中另一個很常見的缺陷。也就是說攻擊者完全可以通過暴力破解的方式獲得使用者名稱與密碼的組合。此種不必要的失誤很有可能給服務帳號帶來極大的安全威脅，值得我們認真對待。

密碼複雜性過低

當大家在將上述安全隱患（例如缺乏帳號鎖定機制）納入解決議程時，也別忘了同時提高密碼複雜性。一旦出於好記的目的而將密碼設定得過分簡單，這就構成了新的安全缺陷，未經授權的惡意攻擊者也很快會趁虛而入。

總結

正如大家所看到的，已經存在且盡人皆知的網頁應用程式安全性漏洞同樣肆虐於網頁服務領域。導致攻擊或滲透出現的前提在細節上可能各有不同，但本質在根源上是相通的，即安全設計上的缺陷加之實際編碼中的疏漏。

希望本文能為用於識別及應對網頁服務、尤其是SOAP網頁服務領域安全弱點的各類技術提供一些啟示。