譯者 | 陳峻
作為一種中介式接口的應用程序編程接口(API)，是一組允許軟件組件彼此交互的協議。他通常可以將基礎架構與運行在其上面的應用程序分離開來，并抽象出系統之間的不同功能。同時，API也能夠讓軟件團隊通過重用代碼的方式，來簡化開發。
隨著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)、速率限制、以及用戶認證等標準化功能，以維護內部服務之間的安全性。
原文鏈接：https://dzone.com/articles/best-practices-to-secure-your-api
譯者介紹
陳峻 (Julian Chen)，51CTO社區編輯，具有十多年的IT項目實施經驗，善于對內外部資源與風險實施管控，專注傳播網絡與信息安全知識與經驗;持續以博文、專題和譯文等形式，分享前沿技術與新知;經常以線上、線下等方式，開展信息安全類培訓與授課。
