干貨 | 最全Web Service滲透測試總結

0x00 前言

補充一下Web Service以及SOAP型這塊資料。

0x01 Web Service基礎

Web Service簡介

Web Service是一個平臺獨立的、低耦合的、自包含的、基于可編程的Web的應用程序，可使用開放的XML（標準通用標記語言下的一個子集）標準來描述、發布、發現、協調和配置這些應用程序，用于開發分布式的交互操作的應用程序。

Web Service技術， 能使得運行在不同機器上的不同應用無須借助附加的、專門的第三方軟件或硬件， 就可相互交換數據或集成。依據Web Service規范實施的應用之間， 無論它們所使用的語言、 平臺或內部協議是什么， 都可以相互交換數據。Web Service是自描述、 自包含的可用網絡模塊， 可以執行具體的業務功能。Web Service也很容易部署， 因為它們基于一些常規的產業標準以及已有的一些技術，諸如標準通用標記語言下的子集XML、HTTP。Web Service減少了應用接口的花費。Web Service為整個企業甚至多個組織之間的業務流程的集成提供了一個通用機制。

Web Service的本質，就是通過網絡調用其他網站的資源。Web Service架構的基本思想，就是盡量把非核心功能交給其他人去做，自己全力開發核心功能。

更簡單地說，Web Service是一種跨編程語言、跨操作系統平臺的遠程調用技術。

Web Service基本原理

Web Service通過HTTP協議發送請求和接收結果時，發送的請求內容和結果內容都采用XML格式封裝，并增加了一些特定的HTTP消息頭，以說明HTTP消息的內容格式，這些特定的HTTP消息頭和XML內容格式就是SOAP協議規定的。

Web Service服務器端首先要通過一個WSDL文件來說明自己有什么服務可以對外調用。WSDL就像是一個說明書，用于描述Web Service及其方法、參數和返回值。WSDL文件保存在Web服務器上，通過一個URL地址就可以訪問到它。客戶端要調用一個Web Service服務之前，要知道該服務的WSDL文件的地址。Web Service服務提供商可以通過兩種方式來暴露它的WSDL文件地址：1.注冊到UDDI服務器，以便被人查找；2.直接告訴給客戶端調用者。

Web Service交互的過程就是，Web Service遵循SOAP協議通過XML封裝數據，然后由HTTP協議來傳輸數據。

Web Service分類

一般的，Web Service分為：

• SOAP型Web Service：SOAP型Web Service允許使用XML格式與服務器進行通信；
• REST型Web Service：REST型Web Service允許使用JSON格式（也可以使用XML格式）與服務器進行通信。與HTTP類似，該類型服務支持GET、POST、PUT、DELETE方法。不需要WSDL、UDDI；

Web Service三要素

Web Service三要素包括SOAP（Simple Object Access Protocol）、WSDL（WebServicesDescriptionLanguage）、UDDI（UniversalDescriptionDiscovery andIntegration）。其中SOAP用來描述傳遞信息的格式， WSDL用來描述如何訪問具體的接口， UDDI用來管理、分發、查詢Web Service 。

Web Service相關技術

SOAP

SOAP（Simple Object Access Protocol）簡單對象訪問協議是交換數據的一種協議規范，是一種輕量的、簡單的、基于XML（標準通用標記語言下的一個子集）的協議，它被設計成在WEB上交換結構化的和固化的信息。SOAP不是Web Service的專有協議。

SOAP使用HTTP來發送XML格式的數據，可以簡單理解為：SOAP = HTTP +XML

SOAP結構如圖：

包括以下元素：

• 必需的 Envelope 元素，可把此 XML 文檔標識為一條 SOAP 消息
• 可選的 Header 元素，包含頭部信息
• 必需的 Body 元素，包含所有的調用和響應信息
• 可選的 Fault 元素，提供有關在處理此消息所發生錯誤的信息

REST

REST（Representational State Transfer）即表述性狀態傳遞，是Roy Fielding博士在2000年他的博士論文中提出來的一種軟件架構風格。它是一種針對網絡應用的設計和開發方式，可以降低開發的復雜性，提高系統的可伸縮性。

REST是一組架構約束條件和原則。滿足這些約束條件和原則的應用程序或設計就是RESTful。需要注意的是，REST是設計風格而不是標準。REST通常基于使用HTTP，URI，和XML（標準通用標記語言下的一個子集）以及HTML（標準通用標記語言下的一個應用）這些現有的廣泛流行的協議和標準。

在三種主流的Web服務實現方案中，因為REST模式的Web服務與復雜的SOAP和XML-RPC對比來講明顯的更加簡潔，越來越多的Web服務開始采用REST風格設計和實現。例如，Amazon.com提供接近REST風格的Web服務進行圖書查找；雅虎提供的Web服務也是REST風格的。

WSDL

WSDL（Web Services Description Language）即網絡服務描述語言，用于描述Web服務的公共接口。這是一個基于XML的關于如何與Web服務通訊和使用的服務描述；也就是描述與目錄中列出的Web服務進行交互時需要綁定的協議和信息格式。通常采用抽象語言描述該服務支持的操作和信息，使用的時候再將實際的網絡協議和信息格式綁定給該服務。

WSDL給出了SOAP型Web Service的基本定義，WSDL基于XML語言，描述了與服務交互的基本元素，說明服務端接口、方法、參數和返回值，WSDL是隨服務發布成功，自動生成，無需編寫。少數情況下，WSDL也可以用來描述REST型Web Service。SOAP也是基于XML（標準通用標記語言下的一個子集）和XSD的，XML是SOAP的數據編碼方式。

WADL

WADL（Web Application Description Language）即Web應用程序描述語言，是一個可用計算機處理的表達基于HTTP的Web應用（如RESTWeb服務）的XML詞匯。WADL描述了Web服務提供的資源及他們的聯系。WADL試圖簡化重用基于HTTP架構的Web服務。它是一個平臺，且與語言無關，并試圖推動除Web瀏覽器的基本使用外的應用重用。

WADL于2009年8月31日由Sun微系統提交至萬維網聯盟，但聯盟目前沒有標準化它的計劃并且它并沒有被廣泛地支持。WADL依照描述基于SOAP的RPC式服務的XML詞匯WSDL定義，用于描述REST服務，而WSDL也可用于描述RESTWeb服務。

WADL主要用于REST基礎。

WADL與WSDL的區別：

• WSDL是面向接口的描述，WADL是面向資源的描述；
• WADL是基于HTTP的，WSDL 2.0是接口獨立的；

UDDI

UDDI（Universal Description Discovery and Integration）即統一描述、發現和集成，是一種用于描述、發現、集成Web Service的技術，它是Web Service協議棧的一個重要部分。通過UDDI，企業可以根據自己的需要動態查找并使用Web服務，也可以將自己的Web服務動態地發布到UDDI注冊中心，供其他用戶使用。

UDDI是核心的Web服務標準之一。它通過SOAP進行消息傳輸，用Web服務描述語言描述Web服務及其接口使用。

SOAP型Web Service服務架構

如圖，Web Service服務提供方將自己的Web服務通過SOAP動態地發布到UDDI注冊中心，其中是以WSDL文件來進行描述，Web Service服務消費方先向UDDI注冊中心通過SOAP請求WSDL文件回來解析服務提供方提供哪些方法后，再和提供方建立XML格式的HTTP通信：

WSDL文檔結構

WSDL文檔結構如下，以本地WSDL文檔為例，：

標簽說明：

• definitions：所有WSDL文檔的根元素都是definitions元素；
• types：數據類型(標簽)定義的容器，里面使用schema定義了一些標簽結構供message引用 ；
• message：通信消息的數據結構的抽象類型化定義。引用types中定義的標簽；
• operation：對服務中所支持的操作的抽象描述，一個operation描述了一個訪問入口的請求消息與響應消息對；
• portType：對于某個訪問入口點類型所支持的操作的抽象集合，這些操作可以由一個或多個服務訪問點來支持；
• binding：特定端口類型的具體協議和數據格式規范的綁定；
• service：相關服務訪問點的集合
• port：定義為協議/數據格式綁定與具體Web訪問地址組合的單個服務訪問點；

那么我們一般如何閱讀WSDL文件呢？——WSDL文檔都是從下往上閱讀的。

先看最底下的service標簽，查看其中port標簽的binding屬性值，然后通過值查找上面的binding標簽：

通過binding標簽可以獲得具體協議等信息，然后查看binding的type屬性：

通過binding的type屬性，查找對應的portType，可以獲得可操作的方法和參數、返回值等：

通過portType下的operation標簽的message屬性，可以向上查找message獲取具體的數據參數：

0x02 編寫Web Service程序

簡單看下各語言怎么編寫Web Service程序。

Java版

編寫接口類ICalculator，其中聲明兩個方法，注意接口要用@WebService修飾：

package com.mi1k7ea;
import javax.jws.WebService;
@WebServicepublic interface ICalculator {    int add(int a, int b);    String concat(String a, String b);}

編寫接口實現類CalculatorImpl，其中重寫實現兩個方法，在@WebService修飾中指定端點接口為com.mi1k7ea.ICalculator且服務名為Calcutator：

package com.mi1k7ea;
import javax.jws.WebService;
@WebService(endpointInterface = "com.mi1k7ea.ICalculator", serviceName = "Calcutator")public class CalculatorImpl implements ICalculator {    @Override    public int add(int a, int b) {        return a + b;    }
    @Override    public String concat(String a, String b) {        return a + b;    }}

編寫Web Service服務端，通過Endpoint.publish()函數來發布指定地址上的Web Service服務：

import com.mi1k7ea.CalculatorImpl;
import javax.xml.ws.Endpoint;
public class WebService {    public static void main(String[] args) {        System.out.println("[*]Start Web Service...");        CalculatorImpl calculator = new CalculatorImpl();
        String address = "http://127.0.0.1:8081/calculator";        Endpoint.publish(address, calculator);
        System.out.println("[*]Web Service is working...");    }}

運行服務即可訪問：

PHP版

參考：https://github.com/snoopysecurity/dvws

NodeJS版

參考：https://github.com/snoopysecurity/dvws-node

.Net版

參考：https://xz.aliyun.com/t/7541#toc-4

0x03 搜索Web Service服務

Google Hack

filetype:asmx inurl:(_vti_bin | api | webservice | ws )allinurl:dll?wsdl filetype:dll
inurl:jws?wsdlinurl:asmx?wsdlinurl:aspx?wsdlinurl:ascx?wsdlinurl:ashx?wsdlinurl:dll?wsdlinurl:exe?wsdlinurl:php?wsdlinurl:pl?wsdlinurl:?wsdlfiletype:jwsfiletype:asmxfiletype:ascxfiletype:aspxfiletype:ashxfiletype:dllfiletype:exefiletype:phpfiletype:plfiletype:wsdl

通過代理流量篩選

可以在如BurpSuite這種代理工具中設定的過濾規則來篩選Web Service請求。比如“.dll?wsdl”、“.ashx?wsdl”、“.exe?wsdl”、“.php?wsdl”等。

Fuzz…

0x04 針對Web Service的滲透測試

Web Service服務也是一些包裝過的接口而已，針對Web Service服務的滲透測試和對常規API滲透測試是一樣的、只是，可以使用安全工具來輔助進行，包括但不限于如下的工具：

• WebScarap
• SoapUI
• WCFStorm
• SOA Cleaner
• WSDigger
• wsScanner
• Wfuzz
• RESTClient
• BurpSuite
• WS-Attacker
• ZAP
• Metasploit
• WSDL Analyze

這里主要講下如何使用BurpSuite和ReadAPI/SoapUI這兩個工具來對Web Service服務進行滲透服務。

ReadyAPI+BurpSuite

網上的資料都是說的用SoapUI NG Pro+BurpSuite組合進行Web Service的滲透測試，但是現在SoapUI NG Pro試用版的下載已經更名為ReadyAPI了。

下載地址：https://smartbear.com/product/ready-api/api-functional-testing/free-trial/

整個過程如圖：

其實就是SoapUI NG Pro作為Web Service的測試工具，Burp作為代理、監聽SoapUI NG Pro用自己構造的payload報文打Web Service的流量報文，其中可以篡改對應的報文參數實現滲透測試。

這里本地以ReadyAPI為例。

先設置Burp代理，在File->Preferences->Proxy中設置Burp代理服務器地址：

然后新建安全測試任務，選擇WSDL相關的API模塊定義：

填寫目標Web Service的WSDL地址，這里以前面編寫的Demo為例：

點擊Next，當WSDL解析完成后，會自動生成一系列的安全測試用例，默認都選上安全測試用例，點擊Finish，然后運行測試用例：

掃描完成之后會給出掃描總結報告、還提供PDF版詳細報告供查閱：

此時Burp中已經監聽到了大量ReadAPI安全測試用例的報文，只需要將對應的報文放到Repeater中修改參數值繼續進行滲透測試或者發到Intruder中進行Fuzzing即可：

后面就是針對常見API接口安全的滲透測試了，套路都是一樣的。

SoapUI+BurpSuite

當使用沒有安全測試用例掃描功能的SoapUI時，也可以用來生成對應格式的報文給Burp進行手工滲透測試。

這里以SoapUI Pro為例，前面的設置操作都是和ReadyAPI一樣，只是沒有了安全測試用例掃描功能而已。

設置好Burp代理，新建SOAP項目，填入WSDL地址完成解析后會顯示如下圖左邊所有的Web Service服務和方法，其中可以單個填入參數值發送對應的請求報文并獲取結果回顯到界面中：

這里Burp監聽到該報文，只需要修改參數值，而無須構造XML格式：

后面就是針對常見API接口安全的滲透測試了，套路都是一樣的。

BurpSuite插件之Wslder

Wslder是BurpSuite，其在Extender的BApp Store中可以直接下載安裝。雖然比前面的方法簡便，但是有時候生成的請求會存在問題導致無法成功發包，此時就需要用到前面的方法了。

安裝成功后，在Requests中右鍵選中Parse WSDL就能直接用了：

解析WSDL完成之后，在Wsdler欄可以看到解析出來對應的Web Service服務和方法以及對應的請求參數樣例等，直接修改對應的參數值即可進行滲透測試：

0x05 Web Service漏洞案例

SOAP型Web Service漏洞和Web漏洞并沒有區別，只是請求的payload構造需要滿足一些格式要求而已，具體還是要看Web Service服務端代碼是怎么寫的。比如命令注入、SQL注入、XSS、XXE、XPath注入、DoS、邏輯漏洞、信息泄露…等等。

這里以DVWS靶場為例演示幾個SOAP類型Web Service請求的漏洞利用。

XSS

換SOAP請求攻擊時，注意點就是在SOAP中XSS payload的尖括號要進行HTML編碼，不然會造成SOAP標簽解析錯誤從而報錯：

此外，一般Web Service服務站點也是支持上傳XML文件的，這里就可以使用xhtml來觸發XML XSS：

    alert(document.location)    

XXE

回顯型XXE，注意exp的XML內容要寫在SOAP的前面才能正常解析利用：

任意用戶枚舉

就是常規的API邏輯漏洞而已，利用響應結果二元組來推斷：

express-fileupload原型鏈污染攻擊

有意思的是，這里有個express-fileupload < 1.1.10版本的原型鏈污染漏洞，可導致DoS（某些情況下可導致任意代碼執行）：

DoS

Web Service服務的交互很多都是用的XML格式數據。請求中的XML數據會由服務端的XML解析器進行解析和處理。

目前主要有兩類XML解析器：

• 基于SAX（Simple API for XML）的XML解析器：內存中最多容納2個元素。在這種情況下，基于SAX的解析器不會存在DoS問題；
• 基于DOM（Document Object Model）的XML解析器：會一次性讀取客戶端存儲的所有XML數據，因此會導致內存中存在龐大的對象數據從而導致存在DoS問題。漏洞根源在于沒有檢查XML中節點的大小和數量；

針對元素名稱的DoS攻擊的示例：

針對元素屬性的DoS攻擊的示例：

針對元素個數的DoS攻擊的示例（也可以通過重復某個特定元素達到同樣效果）：

當然，存在XXE時，就可以進行XXE DoS攻擊：

]><bga>&bga6;bga>

版權申明：內容來源網絡，版權歸原創者所有。除非無法確認，都會標明作者及出處，如有侵權，煩請告知，我們會立即刪除并致歉!