關于如何Hack apis的總結

前言

近日看到國外一篇挺不錯的關于API的攻擊文章，故消化吸收了一下，站在小白的角度結合一下案例來嘗試下關于apis的攻擊思路。算是拓展一下攻擊面，順便補缺補漏下吧。本文主要從API的十個風險點來展開敘說，當然不是只有這10處，像常見的注入就不在這敘說，展開能說好多。

10年前，網絡應用傾向于遵循一種模式，即大部分的應用在呈現給用戶之前都是在服務器端生成的。任何需要的數據都是由生成用戶界面的同一服務器直接從數據庫中收集的。它可能看起來像這樣。

許多現代網絡應用傾向于遵循一種不同的模式，通常被稱為SPA（單頁應用）。在這種模式下，通常有一個API后端，一個JavaScript用戶界面和數據庫。API只是作為網絡應用程序和數據庫之間的一個接口。所有對API的請求都是直接從網絡瀏覽器發出的。

為API測試進行設

Postman是一個方便的應用程序，使API安全測試變得輕而易舉。你可以從其官方網站下載Postman。從本質上講，Postman只是另一個HTTP客戶端，可以用來輕松修改和發送對API的請求。如果你有一個文件中的API請求集合，你可以通過點擊應用程序左上角的導入按鈕，開始將它們導入Postman。

導入集合后，你會看到在Postman中加載的API調用，像這樣。

通過點擊單個的API調用，完整的API請求將在右邊被看到。此外，請求的不同部分將被分成若干部分，如參數、授權、頭信息、請求正文等。這樣方便于我們研究每個部分。

可以與BurpSuite相同的方式修改請求頭和正文。來分析測試案例的響應

Postman中的響應視圖是這樣的，響應也被分成不同的部分，如Body、Cookies、Headers等，所以你可以仔細分析每個部分。

API漏洞類型

API有很多類型和大小，攻擊API的方法也因這些類型和大小而大不相同。所以這里就介紹其中的一些類型。

1、API暴露面

內部使用的API可能會意外地暴露在互聯網上，這可能是由于錯誤的配置，或者只是因為假設沒有人能夠找到它。API的位置可以通過很多方式發現，包括分析JavaScript文件、分析暴露的源代碼、觀察主機名（如api.internal.example.com）和Google dorking。

這里包括之前我分享的一些案例，例如之前的JS泄露OSS的accessKeyId、accessKeySecret

以及常見的JS接口未授權訪問等、除此以外，在外部主機上發現像SSRF這樣的漏洞，可能會讓你獲取到內部的API。

2、配置緩存風險

對于需要認證的API來說，返回的數據往往是動態的，并且是針對每個API密鑰的范圍。例如，以A的身份訪問/api/v1/userdetails 應該返回A的詳細信息，而以B的身份訪問同一終點應該返回B的詳細信息。一個常見的錯誤配置發生在API不使用標準的Authorization 頭，而是使用一個自定義的頭，如X-API-Key 。緩存服務器可能無法識別這是一個經過驗證的請求，并可能將其緩存。

如果是這種情況，并且沒有Cache-Control 或Pragma 頭信息，那么簡單地訪問/api/v1/userdetails 可能會暴露另一個用戶的信息。

3、暴露的Token

通過任何方式發現一個API密鑰，都可能為你提供對API的訪問。更糟糕的是，供內部使用的API往往沒有必要實施復雜的認證流程，因此可能會實施靜態令牌作為其認證。秘密令牌可能在代碼庫、客戶端JavaScript、攔截流量等方面被發現。

例如一次在紅隊演練中內網橫向時獲取到的一個GF配置接口信息。里面暴露了接口的認證key與對應的接口信息，包括可以查看婚姻及伴侶等信息。

4、授權風險/IDOR

授權是檢查一個經過認證的用戶是否可以訪問一個特定的用戶的過程。一個常見的與授權有關的漏洞被稱為不安全的直接對象引用（IDOR）。例如，在一個開票應用程序的API中，我們可能有一個端點，用來獲取發票的詳細信息參數是應該返回的發票的標識符。如果這個端點是安全的，我應該只能得到屬于我的發票的細節。例如，如果我創建了一張ID為1234的發票，那么它應該返回詳細信息。如果我試圖通過瀏覽/api/v1/invoices/?id=1233 來訪問一張我沒有創建的發票，它應該返回一個錯誤。如果我能夠改變標識符來查看其他用戶的發票細節，這就是一個被稱為IDOR的漏洞。也就是所謂的越權。為了應對IDOR問題，今天許多API都利用UUID作為對象的標識符。一個UUID看起來像這樣。f1af4910-e82f-11eb-beb2-0242ac130002，這也是大多數金融行業的修復處理方式。值得注意的是，利用UUID作為標識符并不是緩解IDOR問題的有效方法。事實上，UUID RFC特別指出了這一點。雖然利用UUIDs而不是整數作為對象的ID是很好的做法，但它們絕不應該被用作防止IDOR攻擊的唯一保護措施。特別是可預測的隨機數反而可能會導致情況更加嚴峻。就例如結合前端的敏感信息泄露，有的單位會將其生成算法暴露在前端，并且后端并未有效的進行前后端認證，導致可自行枚舉進行攻擊。

5、未記錄的端點

經常會遇到這樣的情況：嘗試滲透攻擊的API沒有文檔（或者至少沒有你可以訪問的文檔）。同樣常見的是，一個有文檔的API會有超出文檔內容的端點。有時，這些端點的存在可能是一個安全問題--例如，端點可能是為管理目的而設計的，并允許你作為一個低權限用戶執行管理任務。其他時候，這些端點可能會出現漏洞，只是因為它們沒有像那些容易發現的端點那樣被測試。

這里我們可以通過用Burp來檢測，例如通過查看目標選項卡檢查所使用的端點。許多API會給出足夠詳細的錯誤，以列舉未記錄的端點和參數。例如，向/api/v1/randomstring 發送一個空白的POST請求，可能會導致一個錯誤，大意是無效路由，有效路由是[/users,/invoices,/customers] 。

如果你知道一個與API互動的應用程序，你可以分析該應用程序的JavaScript，以收集可能被訪問的API端點的列表。這里建議使用API字典來進行模糊測試。通過遍歷的方式來發現表面不易發現的接口。雖然這塊在下面的解決方法中建議采用類似于swagger這種比較成熟的API功能，但是配置不當也有可能導致對應的接口披露。例如說：

這種就是直接披露了應用環境的接口信息。

6、版本差異風險

當一個組織發布一個API時，它可能與許多不同的應用程序對接。如果API在任何時候被更新，它可能會對這些應用程序中的一個或多個引入破壞性的變化。出于這個原因，多個API版本經常被實施，作為支持舊的API模式的一種手段，同時也為新的用戶逐步升級API。

測試所有版本的API是值得的。舊版本可能仍有安全問題，這些問題后來在新版本中得到了修復，而較新的/邊界/測試版可能引入了新的安全問題。

api版本管理的一個常見模式是:

/api/v1//api/v2//api/beta/

以及未投產時的生產環境入口：

qadevenvdevenv1devenv2preprodpre-prodtesttestingstagingstagedevdevelopmentdeployslavemasterreviewproduatprepVersion2......

7、無速率限制導致批量請求攻擊

大多數時候，API對用戶的請求次數沒有任何保護。這被稱為 "缺乏速率限制"，當攻擊者可以調用API數千次以導致一些非預期的行為時，就會發生這種情況。服務器將試圖滿足這些請求中的每一個，這有可能通過對服務器進行超負荷的請求，使其處于DOS狀態 允許攻擊者快速滲出敏感的用戶信息，如：用戶ID、用戶名、電子郵件等。即枚舉。通過強制執行一個向受害者發送電子郵件/短信的功能，淹沒受害者的收件箱。即短信dos攻擊、郵箱dos攻擊。

例如說看一個攻擊場景，在一個檢查證書的API端點上沒有速率限制。GET /api/v1/user/1234/login/?password=password

通常情況下，你不會看到在這樣的GET請求中發送密碼，但為了本演示的目的，假設你看到了。為了對上述端點中的密碼進行暴力攻擊，攻擊者可以使用BurpSuite’s Intruder ）工具。這個工具允許我們定制不同種類的暴力攻擊，但在這個例子中，我們將給它提供一個簡單的密碼列表。

在幾秒鐘的時間里，入侵者將發出數百個API請求，在每個請求中嘗試使用不同的密碼。

GET /api/v1/user/1234/login/?password=falsepassword1GET /api/v1/user/1234/login/?password=falsepassword2GET /api/v1/user/1234/login/?password=falsepassword3. . .GET /api/v1/user/1234/login/?password=correctpassword!

為了防止速率限制的錯誤，應用程序應該對用戶在一定時間范圍內請求API的頻率進行限制。設置的確切限制將取決于該API或端點的使用情況。

8、接口競爭條件攻擊

競爭條件是指兩個或更多的請求在同一毫秒內被發送到一個API。當一個API沒有處理這種情況的機制時，會導致API以非預期的方式處理這些請求。

一個潛在的競賽條件的攻擊場景可能是在一個有漏洞的電子商務應用程序上兌換折扣或促銷代碼時出現。

POST /api/v1/discountTarget: www.angus.comConnection: close{"code","200","amount":"10"

BurpSuite有一個名為Turbo Intruder的擴展，允許用戶使用內置的race.py 腳本來測試競爭條件。//該工具非常實用測并發，其并發包速率最快可達到每秒2W個。

在Turbo Intruder中配置好攻擊后，攻擊者可以向API發送多個并發請求，以換取這個優惠代碼。

POST /api/v1/discount 200 OKPOST /api/v1/discount 200 OKPOST /api/v1/discount 200 OKPOST /api/v1/discount 404 Not FoundPOST /api/v1/discount 404 Not Found

如果API在收到第一個并發請求后沒有立即使促銷代碼失效，那么折扣金額可能會增加一倍、兩倍。

包括像有的短信炸彈無法正常批量獲取的時候也可利用競爭條件繞過批量獲取。盡管有圖形驗證碼限制，但依舊可繞過。

競爭條件攻擊是攻擊者發送修改資源的請求的速度與應用程序更新該特定資源的速度之間的競賽。

9、XML注入

XXE代表XML外部實體，這種注入漏洞可以在任何使用API處理XML數據的地方測試。SOAP APIs也可能受到XXE注入的攻擊，因為它們是基于XML的。

一個使用XML的API端點看起來是這樣的。

XXE注入是指當攻擊者注入指定DTD之外的自定義外部實體。一旦這些外部實體被API解析，它可以讓攻擊者訪問應用程序的內部文件，升級到SSRF，將敏感數據泄露給攻擊者控制的域或DOS服務器。

這是一個請求的例子，攻擊者注入了一個名為xxe的外部自定義實體，這個實體的目的是為了檢索一個內部文件。

POST /soap/v2/user HTTP/1.1Host: angus.comContent-Type: text/xml<?xml version="1.0" encoding="UTF-8"?><!DOCTYPE ah [<!ENTITY xxeSYSTEM "file:///etc/passwd">]><SOAP-ENV:Envelope><SOAP-ENV:Body><getUser><id>&xxe injection;</id></getUser></SOAP-ENV:Body></SOAP-ENV:Envelope>

如果API允許使用標準的XML解析器來處理數據，那么這個注入的外部實體將被應用程序處理并將/etc/passwd的內容返回給攻擊者。例如說XML的用戶名枚舉。

10、Content類型轉換

即使API可能使用JSON作為數據格式進行通信，底層服務器/框架仍然可能接受其他數據格式，如XML。因此，當看到一個API的content-Type 為application/json 時，仍然可以通過將其值切換為Content-Type: text/xml 來嘗試測試XXE。

例如，如果一個API使用JSON

POST /api/v1/user HTTP/1.1Host: angus.comContent-Type: application/json

它可以被修改為以這種方式發送XML數據。

POST /soap/v2/user HTTP/1.1Host: angus.comContent-Type: text/xml<?xml version="1.0" encoding="UTF-8"?><!DOCTYPE ah [<!ENTITY xxeSYSTEM "file:///etc/passwd">]>

還有的就是我們常見的各類注入攻擊，包括sql注入、命令注入等，就不在敘述了。

小結

1、（API 暴露面）：實施嚴格的部署實踐，通過IAM和網絡分段強制執行最小權限原則。

2、（配置緩存風險）：解決認證引發的API問題的方法是實現Cache-Control 或Pragma 頭并利用標準的Authorization頭。

3、（暴露的Token）：通常可以在API密鑰被部署到不應該部署的地方之前抓到它們。一些代碼庫供應商（包括GitHub）也有能力在推送前檢測API密鑰。其實也就是所謂的自查自檢，這塊個人覺得HAE就是很不錯的工具推薦

4、（授權）：授權問題通常很難以自動化的方式檢測。代碼庫的結構應該被設置成很難在特定的端點上出現授權錯誤。為了實現這一點，授權措施應該盡可能地在堆棧中實施。有可能是在類的層面，或者使用中間件。

5、（未記錄的端點）：擁有一個強大的、結構化的方法和流程來記錄API的功能，可以在以后的道路上節省很多麻煩。Swagger正是這方面的一個優秀標準。此外，最好是在編碼之前用文檔來規劃API的功能，而不是反過來。

6、（版本差異風險）：可以用定義的生命周期來支持API版本。例如，當你發布版本2的API時，你可以通知你的用戶，版本1將達到生命終結（EoL），并在未來的一個特定日期被廢棄。預生產/測試版本只有在經過徹底的安全問題測試后才可以公開訪問。

7、（無速率限制導致批量請求攻擊）：速率限制可以通過許多不同的方式實現。每個賬戶、每個IP地址、每個端點、整個API等等。一些反向代理也可以用來實現整個應用程序的節流，而無需額外的開發。你使用的具體實現方式將取決于你的具體應用的要求。

8、（接口競爭條件攻擊）：緩解競賽條件問題往往意味著犧牲性能。緩解競賽條件的方法包括利用鎖和其他線程安全功能。大多數編程語言都有內置的線程安全功能，但通常需要手動設置。

9、（XML注入）：確保正在利用的XML解析器被設置為不解析XML實體。

10、（Content類型轉換）：這個錯誤實際上只存在于那些被設計為接受多種格式的框架上，其中每種格式對應一種類型的對象。在這些情況下，框架通常會有一個選項，將可用格式列入白名單

對于API的滲透，我們不單單像常規漏洞研究那樣，包括目標采用的API服務、版本、泄露、披露等，包括其傳輸的方法、類型，總之在HTTP中的關聯參數都是我們需要涉及的內容，包括其引用的第三方資源，例如說js等。

*特別說明：本文部分截圖源于互聯網案例