API的安全危機
責編：gltian ｜2020-06-11 13:54:42互聯網商業創新和傳統企業數字化轉型都離不開API經濟或API戰略，可以說，API就是傳統行業價值鏈全面數字化的關鍵環節，API連接的已經不僅僅是系統和數據，還有企業內部職能部門、客戶和合作伙伴，甚至整個商業生態（行業和市場）。但是API面臨的安全威脅，卻很容易被決策者忽視或輕視。本文介紹了API面臨的安全威脅，以及相關軟件開發、運營和保護解決方案。
API為軟件和開發社區帶來許多便利和好處,例如文檔完備、可公開獲取、標準化、無處不在、高效且易于使用等。現在，攻擊者正利用API來實施自動化的“高效攻擊”，從Web應用程序到云計算服務都是目標。例如，我們知道開發人員可以使用API將諸如Web注冊表單之類的資源連接到許多不同的后端系統。但是，包括后端更新等任務的靈活性也為自動攻擊提供了機會。
API的安全難題或者說悖論在于，盡管大多數安全從業者會建議隱藏資源減少暴露面和攻擊面，但業務上成功部署的API卻傾向使資源更加開放和可用。API的安全困局實際上也是現代IT面臨的一個共性問題。對于安全團隊而言，這意味著制定平衡的、良好的API風險緩解策略尤為重要。
圖示：API面臨的安全威脅
OWASP清單：十大API安全風險
除了專注于通用軟件應用程序的安全風險外，OWASP還為API開發人員提供了有用的指導，以降低其實施中的安全風險。鑒于OWASP組織在軟件社區中的突出地位，我們在這里有必要回顧一下2019年OWASP 10大API安全風險（內容取自OWASP網站）：
01、損壞的對象級別授權
API傾向于暴露那些處理對象識別的端點，造成了廣泛的攻擊面訪問控制問題。在每個能夠訪問用戶輸入數據的功能中，都應考慮對象級別授權檢查。
02、損壞的用戶身份驗證
身份驗證機制通常實施不正確，從而使攻擊者可以破壞身份驗證令牌或利用實施缺陷來臨時或永久地假冒其他用戶的身份。損害系統識別客戶端/用戶的能力會整體損害API安全性。
03、數據泄露過多
開發人員傾向于公開所有對象屬性而不考慮其個體敏感性，依靠客戶端執行數據過濾并顯示。
04、缺乏資源和速率限制
通常，API不會對客戶端/用戶可以請求的資源大小或數量施加任何限制。這不僅會影響API服務器的性能，從而導致拒絕服務（DoS），而且還為諸如暴力破解之類的身份驗證漏洞敞開了大門。
05、功能級別授權已損壞
具有不同層級、分組和角色的復雜訪問控制策略，以及管理功能和常規功能之間的模糊不清，往往會導致授權缺陷。通過利用這些問題，攻擊者可以訪問其他用戶的資源和/或管理功能。
06、批量分配
將客戶端提供的數據（例如JSON）綁定到數據模型，而沒有基于白名單的適當屬性過濾，通常會導致批量分配。無論是猜測對象屬性、瀏覽其他API端點、閱讀文檔或在請求有效負載中提供其他對象屬性，都是攻擊者可以修改權限之外的對象屬性。
07、安全性配置錯誤
最常見的安全配置錯誤是不安全的默認配置、不完整或臨時配置、開放的云存儲、錯誤配置的HTTP標頭，不必要的HTTP方法、跨域資源共享（CORS）以及包含敏感信息的冗長錯誤消息導致的。
08、注入
當不受信任的數據作為命令或查詢的一部分發送到解釋器時會發生注入缺陷，例如SQL、NoSQL的命令注入等。攻擊者的惡意數據可能會誘使解釋器執行非預期的命令，或未經授權訪問數據。
09、資產管理不當
與傳統的Web應用程序相比，API傾向于公開更多的端點，這使得文檔的準確性和及時更新顯得尤為重要。健康的主機和最新的API版本能夠有效減輕諸如API版本過期以及調試端點暴露之類的安全問題。
10、日志和監控不足
日志和監控不足，再加上事件響應的缺失或無效集成，使攻擊者可以進一步攻擊系統，長期駐留，并橫向移動到更多系統以篡改、提取或破壞數據。大量入侵調查研究表明，檢測到入侵的平均時間超過200天，而且入侵檢測警告通常來自外部第三方，而不是企業內部安全流程或監控來檢測。
API的五個通用安全要求
正如OWASP清單所示，網絡安全社區開始發現，面向公眾的API往往暴露出大量常見的規范問題。以下是針對API的五項通用網絡安全要求，這些要求適用于從傳統軟件到互聯網新應用的各個領域：
能見度
關于API可見性的諺語是：知識就是力量。應用程序開發人員和用戶需要知道正在發布哪些API、如何以及何時更新它們、誰在訪問它們以及如何訪問它們。了解用戶的API使用范圍是確保API安全的第一步。
訪問控制
API訪問權限通常是不受嚴格控制的，這可能導致意外暴露。確保向不同用戶授予適當的API訪問權限是一項至關重要的安全要求，訪問者必須與企業的身份和訪問管理（IAM）系統進行協調。
Bot緩解措施
在某些環境中，多達90％的應用程序流量（例如，賬戶登錄或注冊、購物車結賬）是由自動化Bot生成的。必須了解和管理流量配置文件，包括區分好Bot和壞Bot，防止自動攻擊的同時又不會阻止合法流量。有效的補充措施包括實施Bot白名單、黑名單和速率限制策略，以及特定于用例和相應API端點的地理圍欄。
防止漏洞利用
API通過消除Web表單或移動應用程序來簡化攻擊過程，從而使攻擊者更容易利用目標漏洞。因此，保護API端點免遭業務邏輯濫用和其他漏洞利用是關鍵的API安全緩解要求。
數據防泄漏
防止由于編程錯誤或安全控制漏洞而產生的API暴露或非授權訪問，是防止數據泄露或丟失的一項至關重要的安全要求。許多API攻擊都是專門為獲取對后端服務器和系統提供的關鍵數據的訪問而設計的。
API社區繼續致力于就最佳安全方法達成更標準化的協議。例如OAUTH之類的行業組織提出了非常有用的API安全性標準要求。最可能的進展是，軟件安全社區將在未來幾年中繼續完善其對各種API安全要求的理解和見解。因此，我們有望看到這一領域的持續發展。
API安全方法
API濫用實例
API的自身設計決定了它是無狀態的，假定初始請求和響應都是獨立的，且并包含完成任務所需的所有信息。無論是直接訪問，或作為移動或Web應用程序的一部分對API進行調用，都可以改善用戶體驗和整體性能。但攻擊者也很容易編寫腳本并自動執行攻擊，如以下兩個示例：
賬戶接管和浪漫欺詐：Zoosk是一個著名的約會應用程序。攻擊者反編譯了Zoosk應用程序以發現賬戶登錄API。然后，他們使用自動化攻擊工具包執行賬戶接管攻擊。在某些情況下，被盜用的賬戶被用來與其他Zoosk用戶建立發展個人關系網絡，當家庭成員突然死亡或生病時，攻擊者會借機向聯系人索要錢財實施詐騙，毫無戒心的用戶通常會將錢捐給攻擊者。在實施Cequence之前，Zoosk的感情詐騙平均每次作案獲取的收益高達1.2萬美元。現在，隨著API安全的加強，此類攻擊幾乎消失，Zoosk不但大大增強了用戶的信心還提高了品牌知名度。
賬戶接管和財務欺詐：API成為自動攻擊目標的另一個案例是某大型金融服務客戶。該客戶發現攻擊者鎖定其移動應用程序登錄API環節來執行賬戶接管。如果成功，攻擊者可通過開放資金轉賬（OFX）API進行轉賬，實施財務欺詐。而OFX是用于在金融服務社區內進行資金轉移的行業標準API，因此，這些API是公開可用的，并且文檔齊全，以方便使用。
API的無處不在和無狀態本質在許多方面都是有益的，但是它們也帶來了傳統安全技術無法解決的眾多挑戰。API沒有客戶端組件，因此傳統的防御技術（如Captchas或JavaScript）和移動SDK工具無法有效地防止自動攻擊。通常，重定向和cookie分配并沒有指定的瀏覽器或者移動應用，結果是API和關聯的應用程序未受到充分保護。