隨著樂娛API介面在現代業務中的優勢和用例的不斷增加，由其固有的弱點所帶來了各種安全風險也逐漸引起了開發界的重視。下面，我將和您深入探討與API漏洞相關的各種風險，同時透過介紹各種常見的API安全實踐，以構建出API介面安全機制。

一、什麼是樂娛介面API安全性?

作為一組服務，API介面實現了一個程式與另一個外部、或內部程式之間的通訊。在談論API安全性時，我們通常指的是保護應用程式的後端服務，其中包括資料庫、使用者管理系統、以及與資料儲存互動的其他元件。因此，API安全性常常包含了採用多種工具和實踐，來保護技術棧的完整性，進而防止惡意攻擊者訪問到敏感的資訊，或執行各種違規操作。

不幸的是，雖然API是現代應用程式的關鍵部分，但它們也是攻擊者訪問敏感資訊的常見目標入口。隨著API越來越成為攻擊的眾矢之的，我們有必要在構建API時，瞭解第三方應用程式是如何透過介面傳輸敏感資料的，並在此基礎上，透過部署API的安全措施，來協助安全團隊評估風險，並提高服務的整體安全態勢。

二、樂娛API介面漏洞風險

由於API往往是可以被公開訪問的，因此它們自然也成為了竊取應用程式邏輯、使用者憑據、信用卡號等敏感資訊的常見途徑。通常，攻擊者會利用API端點中的漏洞，以跨站點指令碼和程式碼注入等方式，獲得針對目標系統的未經授權的訪問、以及其他網路形式的攻擊。

目前，業界比較公認的線上Web應用程式安全專案(Open Web Application Security Project，OWASP)，針對常見的Web API十大漏洞，釋出了基於各類風險的說明與建議。在此，我將和您重點討論如下方面：

失效的使用者身份驗證(Broken User Authentication)：由於API需要依賴那些被嵌入到呼叫中的會話令牌，令牌已對客戶端進行身份驗證，因此如果未能在API中實施多因素身份驗證和基於憑據的登入，而僅靠基本的密碼驗證的話，這樣的驗證機制顯然是不足的。攻擊者可以輕鬆地透過冒充合法使用者的身份，來迫使API錯誤地允許他們訪問到令牌。而且，對於那些長期存在的令牌而言，還會導致攻擊者能夠長期駐留並損害系統。

失效的物件級授權(Broken Object Level Authorization)：在API中，物件級授權是一種程式碼級的控制機制，可用於驗證物件的訪問。而對於那些存在著物件級授權漏洞的API而言，外部使用者可以將自己的資源ID，替換為其他使用者的資源ID。據此，攻擊者能夠訪問到指定的使用者資源，進而未經授權地訪問到敏感資料。

資源缺乏和速率受限(Lack of Resource and Rate Limiting)：當API不限制來自特定客戶端的請求數量和頻率時，它們可能會被迫進行每秒大量的呼叫。同時，API客戶端也可以一次性請求訪問多個資源與記錄，從而使得應用伺服器為了立即給多個請求提供服務，而出現過載。這種由於客戶端的單次過多請求，而阻礙伺服器處理正常請求的能力，便是常見的拒絕服務(DoS)攻擊。此外，缺乏速率的限制還會引發攻擊者，對於身份驗證端點開展暴力破解式的攻擊。

批次分配(Mass Assignment)：批次分配的漏洞發生在自動將使用者的輸入傳遞給物件、或程式變數的API時。雖然此項功能簡化了程式碼的開發，但一些使用者可以透過初始化和覆蓋伺服器端的變數，從而危及到應用程式的安全。也就是說，攻擊者主要會透過在偽造請求時，猜測和提供額外的物件屬性，來達到該目的。此外，他們還可以透過閱讀應用程式的相關文件、或識別出允許其修改伺服器端物件的弱API端點。

安全錯誤配置(Security Misconfigurations)：各種安全錯誤配置都會對API構成不同的威脅，其中包括：

(1)詳細的錯誤訊息(Verbose error messages)：一些API會傳送包含著棧跟蹤和描述性系統資訊的錯誤訊息，讓接收者能夠了解到應用程式是在後臺如何工作的。

(2)錯誤配置的HTTP標頭(Misconfigured HTTP Headers)：標頭會暴露出安全漏洞，攻擊者可以利用此類漏洞，去竊取資料，並執行更深層次的複雜攻擊。

(3)非必要的HTTP方法和服務(Unnecessary HTTP methods and services)：如果管理員未能關閉不必要的服務，那麼惡意攻擊者便可以使用不同的HTTP方法，去修改已釋出的內容與資源。

(4)不安全的預設配置(Insecure default configurations)：API往往會與第三方依賴項相關聯。不過，在預設情況下，此類關聯是不安全的，需要我們透過增強安全態勢，來應對由此擴大的攻擊面。

三、API安全性的優秀實踐

下面我將給出各項有助於緩解API攻擊的優秀實踐：

1.使用節流和速率限制

您可以設定一個臨時狀態，以評估每個API請求，並透過使用反垃圾郵件措施、以及防止濫用等措施，來抵禦拒絕服務攻擊。在實施限流的過程中，您可以重點考慮的因素包括：每個使用者應該允許佔用多少資料、以及何時應該實施限制。

此外，在某些API中，開發人員可以設定“軟”速率限制，允許客戶端在較短的時間內臨時超出請求限制。由於可以處理同步和非同步請求，因此設定超時成為了最直接的避免DoS和蠻力攻擊、以及管理REST API安全性的實踐之一。例如：各種程式語言都可以透過佇列庫目錄來管理請求佇列。其中，請求佇列庫能夠支援已建立的可接受最大請求數的API，並且將其餘的請求放入等待佇列中。

2.掃描API漏洞

為了保持API服務的持續安全性，啟用自動化掃描、漏洞識別、以及在軟體生命週期的各階段及時彌補各種漏洞是至關重要的。自動化的掃描工具透過將應用程式的配置與已知漏洞資料庫進行比較，實現了安全漏洞的自動檢測。

3.對REST API實施HTTPS/TLS

在實踐過程中，我們需要針對每個API實現完整性、機密性和真實性。而作為一種安全協議，HTTPS和傳輸層安全(Transport Layer Security，TLS)可被用於在Web瀏覽器和伺服器之間傳輸經過加密的資料，並在傳輸中保護身份驗證憑據。安全團隊應當考慮使用雙向驗證的客戶端證書方式，為敏感資料和服務提供額外的保護。

此外，在構建安全的REST API時，開發人員不但應當避免因為直接將HTTP重定向到HTTPS處，而可能破壞API客戶端的安全性;而且應當採取適當的措施，來轉移各種跨域資源共享(Cross-Origin Resource Sharing，CORS)和JSONP請求，畢竟兩者往往具有跨域呼叫的各種基本漏洞。

4.限制HTTP方法

REST API允許Web應用執行各種型別的HTTP(動詞)操作。不過，由於HTTP上的資料是未經加密的，一旦我們使用此類HTTP操作，則可能會被某些攻擊向量攔截和利用到。作為一種優秀實踐，我們應該禁止本質上已被證明極其不安全的HTTP方法(如：GET、PUT、DELETE、以及POST等)。如果無法完全禁止此類使用的話，安全團隊也應當採用相應的策略，以嚴苛的允許列表形式，來審查此類方法的使用，進而拒絕所有與列表不匹配的請求。

當然，我也推薦您使用RESTful API身份驗證的各項優秀實踐，來確保請求的客戶端只能在操作、記錄和資源集合上，使用指定的HTTP方法。

5.實施充分的輸入驗證

原則上，我們不應當盲目地信任API客戶端提供的各種資料，畢竟身份驗證伺服器最終可能會執行那些來自未經授權的使用者或應用服務的惡意指令碼。雖然客戶端的驗證已經能夠給出互動式的錯誤指示、以及可接受的使用者輸入建議，但是，安全團隊仍然需要在伺服器端實施輸入驗證機制，以防止有害資料的輸入，並避免不同型別的XSS和SQL隱碼攻擊。

6.使用API介面閘道器

API閘道器能夠有效地將客戶端介面與後端的API集合相分離，提供集中式的資源，以實現API服務的一致性、可用性和可擴充套件性。同時，閘道器也能夠充當反向代理，協調所有API呼叫所需的資源，並在身份驗證後，返回適當的結果。在實踐中，我們可以透過API管理平臺，來處理各種遙測(Telemetry)、速率限制、以及使用者認證等標準化功能，以維護內部服務之間的安全性。

原文連結：

如何安全加固樂娛API介面，遠離漏洞風險？