操作系統型 API 通常是操作系統層對外部提供的接口，開發者通過接口調用，完成對操作系統行為的操作。例如，應用程序調用 Windows APl 或 Linux 標準庫。
遠程應用型 API 是開發者通過標準協議的方式，將不同的技術結合在一起，不用關心所涉及的編程語言或平臺，來操縱遠程資源。例如，Java 通過 JDBC 連接操作不同類型的數據庫。
Web 應用型 API 通常使用 HTTP 協議，在企業與企業、企業內部不同的應用程序之間，通過 Web 開發過程中架構設計的方法，以一組服務的形式對外提供調用接口，以滿足不同類型、不同服務消費者的需求。例如，社交應用新浪微博的用戶登錄。
從上述介紹的 4 種 API 類型可以看出，API 并非新生事物，很早就存在著，只是隨著技術的發展，這個專有名詞的含義已經從當初單一的類庫型 API 或操作系統型 API 擴展到如今的 Web 應用型 API 接口，區是商業反展和業務多樣化驅動技術不斷改進的必然結果。同時，API 的存在對業務的意義也已經從單純的應用程序接口所定義的用于構建和集成應用程序軟件的一組定義和協議，變成了業務交互所在的雙方之間的技術約定。使用 API 技術的業務雙方，其產品或服務與另一方產品和服務在通信過程中，不必知道對方是如何實現的就像在生活中需要使用電，只要按照要求接上電源就會有電流，而不必知道電流的產生原理自己來發電。不同的行業應用可以獨立去構建自己的 API 能力再對外部提供服務，這樣做的好處是大大地節約了社會化服務能力的成本，簡化了應用程序開發的難度，節省了時間，為業務能力的快速迭代提供了可操作的機會。
這里就是介紹簡單的一些常見的接口，可以擴展看書上的。
基于 HTTP 協議的開發接口，這個并不能排除沒有使用其他的協議。
Remote Procedure Calls 遠程過程調用 (RPC) 是一種協議，程序可使用這種協議向網絡中的另一臺計算機上的程序請求服務。由于使用 RPC 的程序不必了解支持通信的網絡協議的情況，因此 RPC 提高了程序的互操作性。在 RPC 中，發出請求的程序是客戶程序，而提供服務的程序是服務器。 RPC（遠程過程調用）是一項廣泛用于支持分布式應用程序（不同組件分布在不同計算機上的應用程序）的技術。RPC 的主要目的是為組件提供一種相互通信的方式，使這些組件之間能夠相互發出請求并傳遞這些請求的結果。 沒有語言限制。
Web service 是系統對外的接口，比如你要從別的網站或服務器上獲取資源或信息，別人肯定不會把數據庫共享給你，他只能給你提供一個他們寫好的方法來獲取數據，你引用他提供的接口就能使用他寫好的方法，從而達到數據共享的目的。
本質上其實 http service 與 web service 差不多，但是 httpservice 通過 post 和 get 得到你想要的東西，而 webservice 就是使用 soap 協議得到你想要的東西，相比 httpservice 能處理些更加復雜的數據類型。同時 http 協議傳輸的都是字符串了，webservice 則是包裝成了更復雜的對象。
這里只是指常見，同時側重于實戰教程中能夠參考的，至于更多的技術可能需要參考其它文章結合，這里無法將所有內容都涉及到，還請諒解。
SOAP（Simple Object Access Protocol）簡單對象訪問協議是交換數據的一種協議規范，是一種輕量的、簡單的、基于 XML（標準通用標記語言下的一個子集）的協議，它被設計成在 WEB 上交換結構化的和固化的信息。SOAP 不是 Web Service 的專有協議。SOAP 使用 HTTP 來發送 XML 格式的數據，可以簡單理解為：SOAP = HTTP +XML。
REST（Representational State Transfer）即表述性狀態傳遞，在三種主流的 Web 服務實現方案中，因為 REST 模式的 Web 服務與復雜的 SOAP 和 XML-RPC 對比來講明顯的更加簡潔，越來越多的 Web 服務開始采用 REST 風格設計和實現。例如，Amazon.com 提供接近 REST 風格的 Web 服務進行圖書查找；雅虎提供的 Web 服務也是 REST 風格的。
WSDL（Web Services Description Language）即網絡服務描述語言，用于描述 Web 服務的公共接口。這是一個基于 XML 的關于如何與 Web 服務通訊和使用的服務描述；也就是描述與目錄中列出的 Web 服務進行交互時需要綁定的協議和信息格式。通常采用抽象語言描述該服務支持的操作和信息，使用的時候再將實際的網絡協議和信息格式綁定給該服務。
根據安全漏洞發生的機理和原因，對 API 安全漏洞做歸類分析，常見的類型如下。
未受保護 API: 在現行的 Open API 開放平臺中，一般需要對第三方廠商的 API 接入身份進行監管和審核，通過準入審核機制來保護 API。當某個 API 因未受保護而被攻破后，會直接導致對內部應用程序或內部 API 的攻擊。比如因 REST、SOAP 保護機制不全使攻擊者透明地訪問后端系統即屬于此類。
弱身份鑒別: 當 API 暴露給公眾調用時，為了保障用戶的可信性，必須對調用用戶進行身份認證。因設計缺陷導致對用戶身份的鑒別和保護機制不全而被攻擊，比如弱密碼、硬編碼、暴力破解等。
中間人劫持: 因 API 的通信鏈路安全機制不全，攻擊者通過攻擊手段將自己成為 API 鏈中的某個受信任鏈，從而攔截數據以進行數據篡改或加密卸載。此類攻擊，通常發生在網絡鏈路層。
傳統 Web 攻擊: 在這里主要是指傳統 Web 攻擊類型，通過攻擊 HTTP 協議中不同的參數，來達到攻擊目的，比如 SQL 注入、LDAP 注入、XXE 等。而攻擊者在進一步攻擊中，會利用權限控制缺失、CSRF 進行橫向移動，從而獲取更大的戰果。
弱會話控制: 有時 API 身份鑒別沒有問題，但對會話過程安全保護不足，比如會話令牌(Cookie 次性 URL、SAML 令牌和 OAuth 令牌）的保護。會話令牌是使 API 服務器知道誰在調用它的主要（通常是唯一的)方法，如果令牌遭到破壞、重放或被欺騙，API 服務器很難區分是否是惡意攻擊行為。
反向控制: 與傳統的交互技術不同，API 通常連接著兩端。傳統的應用中大多數安全協議都認為信任服務器端是可信的，而在 API 中，服務器端和客戶端都不可信。如果服務器端被控制，則反向導致調用 API 的客戶端出現安全問題，這是此類安全問題出現的原因。
框架攻擊: 在 API 安全威脅中，有一些符殊行 D 在不同版本，導致攻擊者攻擊低版本 API 漏洞;同一題，這類威脅統稱為框架攻擊。最常見的比如同一 API 存在不同版本，導致攻擊者攻擊低版本 API 漏洞;同一 API 的不同客戶端調用，可能 PC 端沒有安全問題而移動端存在安全問題等。
在 OWASP API 安全 Top 10 中，OWASP 延續了 Web 安全的傳統，收集了公開的與 API 安全事件有關的數據和漏洞獵人賞金平臺的數據，由安全專家組進行分類，最終挑選出了十大 API 安全漏洞的類型，以警示業界提高對 API 安全問題的關注。這十大 API 安全漏洞類型的含義分別如下。
API1-失效的對象級授權: 攻擊者通過破壞對象級別授權的 API，來獲得未經授權的或敏感的數據，比如通過可預測訂單 ID 值來查詢所有訂單信息。
API2-失效的用戶認證: 開發者對 API 身份認證機制設計存在缺陷或無保護設計，導致身份認證機制無效，比如弱密碼、無鎖定機制而被暴露破解、Token 未校驗或 Token 泄露導致認證機制失效等。
API3-過度的數據暴露: 在 API 響應報文中，未對應答數據做適當的過濾，返回過多的、不必要的敏感信息。比如查詢用戶信息接口時卻返回了身份證號、密碼信息;查詢訂單信息時也返回了付款銀行卡號、付款人地址信息等。
API4-缺乏資源和速率控制: 在 API 設計中，未對 API 做資源和速率限制或保護不足，導致被攻擊。比如用戶信息接口未做頻次限制導致所有用戶數據被盜;文本翻譯接口沒有速率限制導致大量文件上傳耗盡翻譯服務器資源。
API5-失效的功能級授權: 與 API1 類似，只不過此處主要指功能級的控制，比如修改 HTTP 方法，從 GET 改成 DELETE 便能訪問一些非授權的 API;普通用戶可以訪問 api/userinfo 的調用，直接修改為 api/admininfo，即可調用管理類 API。
API6-批量分配: 在 API 的業務對象或數據結構中，通常存在多個屬性，攻擊者通過篡改屬性值的方式，達到攻擊目的。比如通過設置 user.is_admin 和 user.is_manager 的值提升用戶權限等級;假設某 API 的默認接口調用參數為{"user_name":"user", "is_admin":0}，而惡意攻擊者修改請求參數，提交值為{"user_name":"attacker", "is_admin":1}，通過修改參數 is_admin 的值來提升為管理員權限。
API7-安全性配置錯誤: 系統配置錯誤導致 API 的不安全，比如傳輸層沒有使用 TLS 導致中間人劫持;異常堆棧信息未處理直接拋給調用端導致敏感信息泄露。
API8-注入: 與 OWASP Web 安全注入類型相似，主要指 SQL 注入、NoSQL 注入、命令行注入、XML 注入等。
API9-資產管理不當: 對于 API 資產的管理不清，比如測試環境的、已過期的、低版本的、未升級補丁的、影子 API 等接口暴露，從管理上沒有梳理清楚，導致被黑客攻擊。
API10-日志記錄和監控不足: 對 API 缺失有效的監控和日志審計手段，導致被黑客攻擊時缺少告警、提醒，未能及時阻斷。比如沒有統一的 API 網關、沒有 SEIM 平臺、沒有接入 Web 應用防火墻等。
關于這個接口的測試，若不是很熟，不要輕易的測試，同時若全是英文的情況下，無法理解更不要隨便的嘗試，可能會導致數據刪除等情況的發生。同時由于這方面的環境不好搭建，只能在網上尋找相關的內容進行測試，不能保障測試過程中都會一定會遇到存在問題的接口，這里主要是了解測試手段即可。
關于尋找這個接口頁面，可以在前期對網站就是目錄掃描等方式進行獲取，例如這里使用 Google 查詢，這里不一定能百分比搜尋到哦！
語法：edu.cn inurl: asmx?wsdl ##asmx是語言，但是我嘗試切換了一下語言，我發現反而內容更少了。
一般來說看到這個界面，多數都是接口類的頁面。
這里如果想要一次性查看所有內容，可以在后面輸入?wsdl 即可查看 xml 語言，就會顯示所有內容。
?wsdl ##查看xml語言
這里可以使用手動測試，也可以使用工具測試，手動測試走效率上來說肯定是沒有工具測試那么快的，當然我們也要先介紹一下如果使用手動測試。
所謂的手動測試就是在獲取頁面的信息后，點擊進去，然后手動輸入一些信息進行測試，這方面可能需要掌握一定的 API 接口技術能夠，否則很多測試都是在盲猜或盲測，有時候可能測半天都測錯了，自然就不會出現數據。
例如這里點擊登陸賬號驗證，我們在界面中的輸入框中輸入 admin 來進行測試，然后點擊下面的 invoke，點擊完會自動跳轉出現相關的提示信息。
這里顯示數據處理異常，那么就證明沒有 admin 相關的數據，那么就是測試失敗了，那這個整個手動測試流程就是這樣的，admin 不行可以換成其它的，或者進入其它的輸入框中進行測試，均行。
這個工具下載需要輸入聯系方式，這里直接給安裝包吧，如果確實需要下載最新的那么就去官網下載吧，安裝教程我就不說了，別一個軟件都不會安裝…..這個工具確實本質上也是手動測試，只是相比較于在網頁上測試，更為方便點。
SOapUI 官網下載地址[1]
下載好工具后，點擊工具欄 empty，彈出的內容關閉即可，然后再左側邊欄會出現一個 project1 即可。
然后右擊 project1，選擇 add WSDL 即可。
在彈出的窗口中，將剛剛的地址復制進行即可，但是要注意一定要復制的是 xml 的鏈接，也就是在地址后面添加?wsdl 的 xml 狀態的結果。
然后再看左側邊欄就會出現相關的內容了，然后雙擊點進去，修改相關的內容，即可看到相關的結果，這個就是工具測試，當然這個工具有點類似于手工測試。
這個工具由于沒找到新版的破解版，都是老版的，同時雖然可以試用，但是在時間操作中，發現需要發送郵箱，但是不知道為何一直發送失敗。屬于這里也就不提供了，我這里大概截圖看一下如何使用吧，同時由于我這個找到的地址是國內了，也就不使用這個工具掃描了，畢竟有影響。這個工具會自動去分析是否存在一些安全漏洞，屬于全自動的，只需要將地址復制上去即可。
這里點擊工具欄選擇下方的創建安全測試。
這里我們再選擇需要創建的類型，根據我們剛剛獲取到的是 wdsl，那么我們就選擇左邊這個。
將剛剛獲取的地址輸入進去即可。
這里就是選擇你需要測試的安全漏洞，這里可以直接點擊默認。
添加完畢后，就會進行自動測試，這里只需要工具測試完畢即可，該工具會自動生成一個報告。
報告會在當前了下生成。
關于 Swagger，其實是 java 中經常使用到的第三方軟件，類似于數據庫管理系統 phpMyadmin 一樣。專業的解釋就是 Swagger 是一款 RESTFUL 接口的文檔在線自動生成+功能測試功能軟件。Swagger 是一個規范和完整的框架,用于生成、描述、調用和可視化 RESTful 風格的 Web 服務。目標是使客戶端和文件系統作為服務器以同樣的速度來更新文件的方法,參數和模型緊密集成到服務器。這個解釋簡單點來講就是說，Swagger 是一款可以根據 resutful 風格生成的生成的接口開發文檔，并且支持做測試的一款中間軟件。
這里同樣都是可以采取很多種方式進行查找。
關于尋找 Swagger 其實可以使用目錄掃描，JS 資源探針，或者瀏覽器插件等，這里舉例子就使用瀏覽器插件來演示。
"Swagger" && title=="Swagger UI"
同樣這里也是分為手動測試與自動化測試，至于手動測試，這里就簡單的演示一下吧，手動測試確實是比較麻煩的。
簡單來說，手動測試就是在這些框內插入一下相關的數據進行測試，可以是 sql 注入語句、xss 語句、xml 語句以及一些執行代碼或信息泄露等。
這里是找了一個其它國家的頁面，可以看到全部都是英文，有時候確實無從下手，就算有翻譯軟件，也不一定能夠翻譯準確。
比如上圖都是英文，可能考翻譯軟件，也會出現不知道如何測試的情況，那么下面這個應該就能一目了然了，當然我不會去操作，僅僅的展示，由于都是國內網站。這里都很明顯告訴你是干嘛了，還能不知道怎么測試么，就是輸入相關的內容進行測試，當然手動測試比較慢，也可以借助工具來進行測試。
這里需要獲取 josn 地址，然后將地址導入。
在頁面中都會存在一個這個藍色鏈接，打開就是 josn 地址了。
這里將地址導入即可，可以看到下圖，先選在 Swagger，在彈出的對話框中輸入 josn 地址。
這里輸入 josn 地址后，點擊 ok，但是會出現一種情況就是無法獲取到，主要原因就是由于有時工具無法訪問國外地址，就會導致測試國外地址的時候會出現無法訪問的情況。
這里費勁千辛萬苦終于找到一個能夠添加成功的，剩下的測試完全就是替換數據了，然后看內容。
這里的自動化工具是源自于 github 上的工具。
swagger-exp[2]
swagger-hack[3]
該腳本需要 python3.0 的環境，加上-h 可以顯示相關的參數，通常直接使用-u 即可。
這里測試一定要加上 josn 的地址，而不是頁面地址。
在當前目錄下會生成一個結尾為 csv 的表格，在這里面重點關注響應 200 的一行，不過我這里翻了一下啥數據沒有，我也懶得再去尋找有內容的數據了。
webpack 是一個模塊打包器（module bundler），webpack 視 HTML，JS，CSS，圖片等文件都是一種資源 ，每個資源文件都是一個模塊（module）文件，webpack 就是根據每個模塊文件之間的依賴關系將所有的模塊打包（bundle）起來。
這個尋找頁面我就不介紹了采用的方式和 SOAP 類尋找頁面的方式都是一樣的。
這里最好是工具測試，使用手動測試的話比較麻煩。
這個工具需要安全的庫挺多的，最好按照 GitHub 上描述進行操作。
Packer-Fuzzer[4]
這里需要提前測試是否成功，以免出現部分庫不正確的情況。
這里把我們尋找到的地址使用-u 添加地址進行掃描。
python PackerFuzzer.py -u 地址
在當前目錄下的 reports 中能夠看到的 word 版報告以及 html 版的報告，可以看到這里泄露了一個郵箱地址，以及手機號碼。
[1] SOapUI 官網下載地址: https://www.soapui.org/downloads/soapui/
[2] swagger-exp: https://github.com/lijiejie/swagger-exp
[3] swagger-hack: https://github.com/jayus0821/swagger-hack
[4] Packer-Fuzzer: https://github.com/rtcatc/Packer-Fuzzer
原文轉載自：https://mp.weixin.qq.com/s/yEMr5iDEN_5u3_aJpIKHVA