API接口滲透測試技巧彙總

大家好，我是老李，今天上午給大家分享了一篇關于《如何通過零信任架構實作 API 安全》的文章，主要介紹了API的安全授權問題。現在再給大家分享一個關于API接口滲透測試技巧的知識，希望能夠給大家日常工作和學習帶來啟發。

1 API 接口介紹

1.1 RPC（遠端過程調用）

遠端過程調用（英語：Remote Procedure Call，縮寫為 RPC）是一個計算機通信協定。該協定允許運作于一台計算機的程式調用另一台計算機的子程式，而程式員無需額外地為這個互動作用程式設計。如果涉及的軟體采用面向對象程式設計，那麼遠端過程調用亦可稱作遠端調用或遠端方法調用，例：Java RMI。

RPC 一般直接使用 TCP 協定進行通信，通常不涉及到 HTTP。HTTP 下面有2種技術：

• XML-RPC（https://zh.wikipedia.org/wiki/XML-RPC）
• JSON-RPC（https://zh.wikipedia.org/wiki/JSON-RPC）

Web service 和 RESTful API 都可算作遠端過程調用的子集。

1.2 Web Service

Web Service 是一種服務導向架構的技術，通過标準的Web協定提供服務，目的是保證不同平台的應用服務可以互操作。

根據 W3C 的定義，Web 服務（Web service）應當是一個軟體系統，用以支援網絡間不同機器的互動操作。網絡服務通常是許多應用程式接口（API）所組成的，它們透過網絡，例如國際網際網路（Internet）的遠端伺服器端，執行客戶所送出服務的請求。

盡管W3C的定義涵蓋諸多相異且無法介分的系統，不過通常我們指有關于主從式架構（Client-server）之間根據 SOAP 協定進行傳遞 XML 格式消息。無論定義還是實作，Web 服務過程中會由伺服器提供一個機器可讀的描述（通常基于WSDL）以辨識伺服器所提供的 Web 服務。另外，雖然 WSDL 不是 SOAP 服務端點的必要條件，但目前基于Java 的主流 Web 服務開發架構往往需要 WSDL 實作用戶端的源代碼生成。一些工業标準化組織，比如 WS-I，就在 Web 服務定義中強制包含 SOAP 和 WSDL。

Web Service 是一種比較“重”和“老”的 Web 接口技術，目前大部分應用于金融機構的曆史應用和比較老的應用中。

1.3 RESTful API

REST，全稱是 Resource Representational State Transfer，通俗來講就是，資源在網絡中以某種表現形式進行狀态轉移。分解開來：

• Resource：資源，即資料（前面說過網絡的核心）。比如 newsfeed，friends等；
• Representational：某種表現形式，比如用JSON，XML，JPEG等；
• State Transfer：狀态變化。通過HTTP動詞實作。

RESTful API 就是符合 REST 風格的 API，傳遞資料也是2種形式：

• XML，少見
• json，常見，現在 Web 應用基本使用這種形式的 API。

1.4 MVC、MVP、MVVM

Web 應用程式和 APP 應用程式的 API 跟目前的流行架構和模式相關，主要有3種模式：MVC、MVP、MVVM。

MVC 将整個應用分成 Model、View 和 Controller 三個部分，而這些組成部分其實也有着幾乎相同的職責。

• 視圖：管理作為位圖展示到螢幕上的圖形和文字輸出；
• 控制器：翻譯使用者的輸入并依照使用者的輸入操作模型和視圖；
• 模型：管理應用的行為和資料，響應資料請求（經常來自視圖）和更新狀态的指令（經常來自控制器）；

此類模式和架構的應用越來越多導緻 API 接口的應用也越來越流行。想了解更多可以在網上查找相關資料。

2 API 測試環境和測試工具

2.1 Web Service 測試

2.1.1 找 Webservice 接口

• Google hackinginurl: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 wsdl
• fuzzing
• 爬蟲

2.1.2 測試工具

涉及主要工具：

• Soap UI PRO，滲透測試流程的發起，通信封包的解析、集合payload之後通信封包的重新組裝等，14天試用，可以做自動化測試。
• SoapUI Free，手工測試
• SOAPSonar，SOAP UI 的替代。
• Burp Suite，代理攔截，跟蹤通信過程和結果，對通信進行重放和二次處理等。
• WSSAT
• WS-Attacker

2.1.3 測試項目

• Fuzzing
• XSS /SQLi/ Malformed XML
• File Upload
• Xpath Injection
• XML Bomb (DoS)
• Authentication based attacks
• Replay attacks
• Session fixation
• XML Signature wrapping
• Session timeout
• Host Cipher Support/ Valid Certificate/ Protocol Support
• Hashing Algorithm Support

2.1.4 手工測試方法

主要使用 Soap UI Open Source，有安全測試Case，需要配置 SOAP 代理到 Burp，資料流，現在的版本是5.4.0。

代理配置

可以用 Burp 重放 SOAP 的探測 Payload。使用 Soap UI Open Source，測試步驟：

1. 建立工作空間
2. 建立 SOAP 項目
3. 增加 WSDL，配置名稱和 WSDL 連結
4. 選擇要測試的 TestSuite，增加一個安全測試
5. 選擇測試的類型，運作測試

2.1.5 自動化測試

SOAP 配置，2步，“File”-“Preference”-“Proxy”，設定 Burp 代理

直接在 Soup UI 主菜單上選擇運作一個測試。

在彈出視窗中輸入 WSDL 位址。

SUAP UI 會自動探測接口。然後在項目-測試Case的右鍵菜單中選擇安全測試

運作安全測試。

Burp 代理會捕獲所有的測試請求

其他工具介紹：WSSAT，選擇加載存在 WSDL 清單的檔案，運作。

WS-Attacker

AWVS 的掃描也能直接測試 Web Service

2.2 RESTful API 測試

2.2.1 測試工具

• 常見的浏覽器插件Chrome Restlet Client

- Firefox RESTClient

• 用戶端工具Postman

- Swagger

通常使用 Postman 的情況多些，有機會的話問下開發如何配置測試環境，直接配置一套一樣的。

Postman 的代理配置：

3 常見 API 相關漏洞和測試方法

還是主要以 Restful API 說明。

3.1 邏輯越權類

本質上可以說是不安全的直接對象引用，可以通過修改可猜測的參數擷取不同參數下的響應結果。參數可以是使用者名、使用者 ID，連續的數字，變形的連續數字（各種編碼或哈希），通過直接修改參數值完成越權的操作。

示例：

• https://a.xx.com/bug/view?bug_no=189225
• https://a.xx.com/bug/view?bug_no=150462
• https://a.xx.com/bug/view?bug_no=140374
• https://a.xx.com/bug/view?bug_no=106709

3.2 輸入控制類

XXE，Restful API 的注入漏洞，XSS，溢出，特殊字元的處理。

示例：

• https://a.xx.com/bug/view?bug_no=211103
• https://a.xx.com/bug/view?bug_no=132270
• https://a.xx.com/bug/view?bug_no=8714

3.3 接口濫用

沒有請求頻率限制導緻的各種爆破和周遊，如短信驗證碼爆破、登入爆破、手機号周遊、身份證周遊等。

示例：

• https://a.xx.com/bug/view?bug_no=141419
• https://a.xx.com/bug/view?bug_no=66571
• https://a.xx.com/bug/view?bug_no=36058
• https://a.xx.com/bug/view?bug_no=147334

3.4 資訊洩露

包括越權導緻的資訊洩露、畸形請求導緻的報錯響應。

示例：

• https://a.xx.com/bug/view?bug_no=171313
• https://a.xx.com/bug/view?bug_no=160095
• https://a.xx.com/bug/view?bug_no=127457

3.5 HTTP 響應頭控制

關于響應頭：

• 發送 X-Content-Type-Options: nosniff 頭。
• 發送 X-Frame-Options: deny 頭。
• 發送 Content-Security-Policy: default-src 'none' 頭。
• 删除指紋頭 - X-Powered-By, Server, X-AspNet-Version 等等。
• 在響應中強制使用 content-type。

3.6 服務端配置漏洞

如服務端版本資訊洩露，或服務端程式本身存在漏洞等。

4 API 安全加強

根據上面講的測試方法，一般需要做好：

1. 認證和授權控制
2. 使用者輸入控制
3. 接口請求頻率的限制
4. 輸出控制
5. 添加安全響應頭參數

參考 API-Security-Checklist 和曆史上的滲透測試結果設計适合自己組織的 API 安全開發規範。

參考

Web Service 的滲透測試參考：

https://blog.csdn.net/cq1982/article/details/44728489

https://t0data.gitbooks.io/burpsuite/content/chapter17.html

https://www.owasp.org/index.php/Web_Service_Security_Testing_Cheat_Sheet

https://www.soapui.org/security-testing/getting-started.html

http://blog.securelayer7.net/web-services-api-penetration-testing-part-2/

https://www.soapui.org/security-testing/getting-started.html

https://www.anquanke.com/post/id/85910

Restful API 的參考：

https://github.com/shieldfy/API-Security-Checklist

https://www.owasp.org/index.php/REST_Security_Cheat_Sheet

來源：先知社群