網頁 API 駭客方法論

近年來，隨著移動設備和物聯網設備等異構設備的大量使用，基於網頁的應用程式介面（API）的使用急劇增加。這些設備經常通過API與後端網頁伺服器進行通信。為了使這些基於網頁的API更加用戶友好，開發人員常常採用簡化安全措施，這使得線上網路服務容易受到各種攻擊的威脅。攻擊者使用各種技術來識別和利用這些API的漏洞。要入侵一個API，攻擊者需要識別API技術、安全標準以及可供利用的攻擊表面。駭客入侵一個網頁API通常包括以下階段：

1. 識別目標
2. 檢測安全標準
3. 識別攻擊表面
4. 發動攻擊

識別目標

在駭客入侵一個API之前，首先需要識別目標及其範圍：

1. 識別API格式，例如REST API使用JSON，SOAP API使用XML。如果這些格式被不正確使用，它們可能為漏洞鋪平道路。由於這些格式易於理解，攻擊者可以輕鬆地操縱這些格式編碼的消息來識別目標及其範圍。
2. HTTP請求與回應，如果 HTTP 請求和回應的標頭都以純文字傳輸，攻擊者可以輕鬆地操縱這些標頭以識別目標。

檢測安全標準

儘管API聲稱具備安全性，因為它們納入了諸如OAuth和SSL等安全標準，但它們仍包含許多可以被攻擊者利用的漏洞。

• 像SOAP和REST這樣的API實施不同的身份驗證/授權標準，如OpenID Connect、SAML、OAuth 1.X和2.X，以及WS-Security。
• SSL提供API消息的傳輸層安全性，以確保通過加密實現機密性和通過簽名實現完整性。儘管SSL用於安全性，但在大多數API消息中，只有敏感用戶數據，如信用卡詳細資訊，被加密，而其他信息保留為純文本。

識別攻擊表面

在識別要攻擊的目標API及其安全實現之後，攻擊者需要識別用於發動攻擊的攻擊表面。對於基於UI的應用程式，很容易找到攻擊表面，因為我們可以在網頁上看到各種輸入欄位。然而，識別API的攻擊表面是不同的，因為它沒有內建的UI欄位；我們只能看到API端點。要識別API的攻擊表面，攻擊者需要了解API的端點、消息、參數和行為。

• API Metadata 漏洞顯示了大量技術訊息，如路徑、參數和消息格式，這對於執行攻擊很有用。REST API 使用 Metadata 格式，如Swagger、RAML、API-Blueprint和I/O Docs，而SOAP API使用WSDL/XML-Schema等。

• API 探索，如果一個 API 沒有 Metadata ，攻擊者可以監控和記錄API與現有客戶端之間的通訊，以識別初始的攻擊表面。例如，攻擊者可能使用一個使用目標 API 的手機應用程式，配置本地代理以記錄流量，最後將手機設備配置為使用此代理來訪問API。然後，攻擊者使用自動化工具從記錄的流量生成 Metadata 。

• 暴力破解 如果以上提到的技巧都不起作用，攻擊者會嘗試通過暴力破解來識別API的路徑、參數等。開發人員常用的API路徑包括api、/api/v2、/apis.json等。

• 分析網頁API的請求和回應 攻擊者可以使用工具如Postman來攔截和分析目標網頁API、網站和WEB服務。

發動攻擊

在識別目標API、分析消息格式和安全標準，以及識別攻擊表面之後，攻擊者會對目標API執行各種攻擊，以竊取敏感信息，如信用卡詳細信息和憑證。

對API執行的各種攻擊如下：

• Fuzzing 攻擊者使用模糊測試技巧，反覆向目標API發送一些隨機輸入，以生成揭示關鍵信息的錯誤消息。為了執行模糊測試，攻擊者使用自動化腳本，發送大量帶有不同輸入參數組合的請求。攻擊者使用工具如Fuzzapi 來對目標API執行模糊測試。

• 無效輸入攻擊 在某些情境下，由於結構性的原因，模糊測試很難執行。在這種情況下，攻擊者將提供無效的輸入給API，例如將文字發送到數字的位置，將數字發送到文字的位置，發送比預期更多的字符，發送空字符等，以從意外的系統行為和錯誤消息中提取敏感信息。同時，攻擊者還會操縱HTTP標頭和值，針對API邏輯和HTTP協議進行攻擊。

• 惡意輸入攻擊 在上述討論的攻擊中，攻擊者試圖從意外的系統行為或錯誤消息中檢索敏感信息。一種更危險的攻擊是攻擊者直接注入惡意輸入，以同時針對API和其主機進行攻擊。

• 注入攻擊，與傳統的網頁應用程式一樣，API也容易受到各種注入攻擊的威脅。例如，考慮以下正常的URL：http://billpay.com/api/v1/cust/459

  對於上述的URL，API根據客戶ID 459 從數據庫中使用以下SQL查詢擷取客戶詳細信息

  SELECT * FROM Customers where custID='" + custID + "'"
  
  # custID 被替換為 459
  SELECT * FROM Customers where custID='459'
  

  在上述URL中，假設攻擊者注入惡意輸入 http://billpay.com/api/v1/cust/'%20or%20'1'='1'
  結果的惡意SQL查詢是

  "SELECT * FROM Customers where custID='' or '1' = '1'"

  SELECT * FROM Customers where custID='' or '1' = '1'
  

• 利用不安全的配置

  • 不安全的SSL配置：SSL配置中的漏洞可能允許攻擊者執行中間人攻擊。例如，使用自簽名的SSL憑證進行安全API訪問可能允許攻擊者執行中間人攻擊。攻擊者可以嗅探API和客戶端之間的流量，操縱客戶端證書，並開始監控或操縱客戶端和API之間的加密流量。
  • 不安全的直接物件引用（IDOR）：通常，直接物件引用用作API調用的參數，對於用戶無權訪問的物件不強制實施訪問權限。攻擊者可以通過API元數據識別這些漏洞，然後利用它們來識別參數，嘗試參數的所有可能值以訪問用戶無權訪問的數據。
  • 不安全的會話/身份驗證處理：存在漏洞，如重複使用會話令牌、連續會話令牌、長會話令牌超時、未加密的會話令牌和將會話令牌嵌入URL中，這些漏洞允許攻擊者劫持和接管客戶端會話，竊取或操縱客戶端和API之間的消息。

• 登入/憑證填充攻擊
  攻擊者經常針對登入和驗證系統，因為對這些系統的攻擊通常難以使用典型的API安全解決方案來檢測和阻止。攻擊者執行登入攻擊或憑證填充攻擊，以利用在多個平台上重複使用的密碼。大多數用戶使用相同的密碼訪問不同的網絡服務。攻擊者可以利用從一個帳戶竊取的憑證，用於驗證其他服務。

  憑證填充攻擊不涉及猜測密碼或暴力破解密碼；相反，攻擊者嘗試使用自動化工具（如Sentry MBA和PhantomJS）自動化所有先前識別的憑證對，以侵入帳戶。這些攻擊還可以用來破壞基於API的服務，通過阻止合法用戶登錄，降低前端API的用戶體驗和功能。攻擊者通常使用機器人進行不同的登入嘗試，使用先前偷取的數據（從先前的登錄中獲得）或屬於一個帳戶的泄漏信息，來侵入其他帳戶/服務，或向服務器發送大量的登入請求，直到找到正確的組合為止。一旦攻擊成功，攻擊者不僅接管了用戶帳戶，還可以從該帳戶執行不合法的交易，並進行欺詐的線上活動。

• API DDoS 攻擊

  DDoS 攻擊涉及使用多個受感染的計算機（僵屍網絡）向API注入大量流量，以延遲合法用戶的API服務。儘管實施了許多速率限制約束以保護伺服器免受崩潰，但這些約束可能無法阻止服務延遲（API回應），因此降低了API的用戶體驗。

  攻擊者通常使用僵屍網絡來執行這些攻擊，這些僵屍網絡被創建來發現API速率限制控制並增加攻擊的可能性。除了來自合法用戶的常規流量之外，攻擊者的請求也可以繞過API安全管理系統、負載平衡器和其他安全實施。大多數這些攻擊可能不是容積型的。它們也可以利用某些API漏洞來破壞API服務。例如，一名入侵API的攻擊者可以消耗為API保留的CPU和其他記憶體資源，以盡可能延遲服務。

• OAuth 攻擊

1. 資源擁有者: 資源擁有者也被稱為使用者，他/她授權應用程式訪問自己的帳戶。對於應用程式的訪問是有限或有條件的，例如僅提供讀取和寫入權限。
2. 授權/資源伺服器 (API): 資源伺服器提供安全的使用者帳戶，授權伺服器驗證使用者身份，然後提供存取權杖 (access token) 給應用程式。
3. 客戶端或應用程式: 這是一個尋求訪問使用者帳戶的應用程式。要訪問帳戶，使用者必須授權應用程式，然後 API 應該驗證此授權。

• 授權攻擊

1. 使用者通過使用者代理 (user agent) 將 GET 請求傳遞給客戶端，以啟動授權過程。這個操作可以通過客戶端網站上顯示的「登入或連接」按鈕執行。
2. 客戶端使用以下參數將使用者代理重新導向到授權伺服器：
   • response_type: 用於通知伺服器要執行哪些權限的代碼
   • client_id: 分配給客戶端的ID
   • redirect_uri: 當授權碼提供時，授權伺服器將使用者代理重新導向的URI
   • scope: 定義對應用程式的存取級別
   • state: 用於安全實施的不透明值。此值還用於在請求和回調之間維護狀態。
3. 當使用者經過驗證並獲得授權以訪問資源時，使用者代理被授權伺服器重新導向到 redirect_uri。伺服器使用以下參數執行此操作：
   • Code: 授權碼
4. 獲得授權碼後，客戶端通過在請求的主體中添加以下參數來請求訪問權杖：
   • grant_type: Authorization_code
   • code: 在前一條消息中收到的授權碼
   • redirect_uri: 在第一個請求中使用的URI

REST API 的弱點掃描

REST API的漏洞引入了與Web應用程序和網站的安全問題相同的風險。這些風險包括關鍵數據洩漏、中間數據篡改等。對REST API進行全面掃描可以揭示攻擊者可以利用的各種潛在漏洞。攻擊者可以使用工具，如Astra、Fuzzapi、W3af和Appspider來執行REST API的漏洞掃描。

▪ Astra 來源：https://github.com
攻擊者使用Astra工具來檢測和利用REST API中的潛在漏洞。Astra可以發現和測試驗證，例如登錄和登出；這使得攻擊者可以輕鬆地將其整合到CICD流程中。Astra可以作為輸入值調用API集合，因此也可以用於掃描REST API。Astra允許攻擊者檢測易受攻擊的REST API，如XSS、SQL注入、信息洩漏、CSRF、破壞的身份驗證和會話管理、JWT攻擊、盲目XXE注入、CRLF檢測、CORS配置錯誤和速率限制等。

以下是一些REST API漏洞掃描工具：
▪ Fuzzapi (https://github.com)
▪ w3af (https://w3af.org)
▪ appspider (https://www.rapid7.com)
▪ Vooki (https://www.vegabird.com)
▪ OWASP ZAP (https://www.zaproxy.org)

繞過IDOR (Insecure Direct Object Reference) 通過參數汙染

不安全的直接物件引用 (IDOR) 是一種漏洞，當開發人員洩漏對內部數據實施對象的引用，例如數據庫鍵、目錄和其他文件時，攻擊者可以利用它來修改這些引用並未經授權地訪問數據。這些IDOR可以通過反覆提供相同參數名稱但具有唯一值來繞過。例如，假設受害者的 user_id 是 321。攻擊者可以將此 user_id 值更改為 654（另一個 user_id 值）以識別IDOR。如果頁面不容易受到IDOR的攻擊，它會生成「401 未經授權」的錯誤消息。要通過參數汙染繞過IDOR，攻擊者發送兩個 user_id 參數作為請求，其中一個參數附加受害者的 user_id，另一個參數附加攻擊者自己的 user_id。例如，考慮以下請求：

[api.xyz.com/profile/user_id=](http://api.xyz.com/profile/user_id=) 321

攻擊者使用參數汙染技術操作上述請求以繞過IDOR：

[api.xyz.com/profile/user_id=654&user_id=321](http://api.xyz.com/profile/user_id=654&user_id=321)

當上述請求在REST API端點處理時，應用程序驗證第一個 user_id 參數，確保發送請求的用戶已在GET請求中包含自己的 user_id。因此，攻擊者可以通過提供兩個 user_id 參數（一個屬於受害者，另一個屬於攻擊者）來繞過IDOR。應用程序被欺騙認為這是有效請求。攻擊者使用工具，如Burp Suite，來代理流量並攔截所有流量到REST API端點。然後，他們使用參數汙染技術將攻擊者的 user_id 和受害者的 user_id 都包含在GET請求中，以未經授權的方式訪問並擷取受害者帳戶中的敏感數據。使用這種技術，攻擊者還可以危害應用程序的功能，因為應用程序中的每個參數都容易受到這種攻擊。