在本文中，我們將要對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是竊取來的，在其過期之前應該還是可以奏效一段時間。但如果想要獲取更多信息以查看或修改密碼，攻擊者只能憑借自己的運氣。
然而當下太多的移動應用程序利用基本信息驗證與網頁服務進行交互，因此我們常常會發現有些移動應用會在每個發往網頁服務的請求中都夾帶驗證信息！
如果用戶的手機處於開機狀態並連入允許公開訪問的Wi-Fi網絡，而網頁服務使用的又不是HTTPS協議，這就意味着整個傳輸過程利用的負載媒介相當於純文本。讓我們探究一下破解基本驗證信息到底有多容易。
將基本驗證信息字符串發送至Burp解碼器
正如大家所見，用戶名為guest，而密碼也為guest。在這里我再次強調，移動應用程序中時刻充斥着這類簡單漏洞。
缺乏賬號鎖定機制
輸入一定次數的錯誤口令后，賬號仍未轉為鎖定狀態，這是當前網頁服務中另一個很常見的缺陷。也就是說攻擊者完全可以通過暴力破解的方式獲得用戶名與密碼的組合。此種不必要的失誤很有可能給服務賬號帶來極大的安全威脅，值得我們認真對待。
密碼復雜性過低
當大家在將上述安全隱患（例如缺乏賬號鎖定機制）納入解決日程時，也別忘了同時提高密碼復雜性。一旦出於好記的目的而將密碼設置得過分簡單，這就構成了新的安全缺陷，未經授權的惡意攻擊者也很快會趁虛而入。
總結
正如大家所看到的，已經存在且盡人皆知的網頁應用程序安全漏洞同樣肆虐於網頁服務領域。導致攻擊或滲透出現的前提在細節上可能各有不同，但本質在根源上是相通的，即安全設計上的缺陷加之實際編碼中的疏漏。
希望本文能為用於識別及應對網頁服務、尤其是SOAP網頁服務領域安全弱點的各類技術提供一些啟示。