應用編程接口(API)一直是信息安全領域的熱門討論話題，這是有原因的：最近的一些高知名度網站安全泄露事故(包括Pinterest和Instagram)都涉及API。

在2014年1月，Snapchat數據泄露事故導致約460萬用戶受影響，而該事故的根源就是不安全的API。雖然API并不是直接攻擊目標，但API允許攻擊者大規模匹配Snapchat用戶的手機號碼與用戶名。

在本文中，我們將探討不安全的API如何以及為何會給企業及用戶構成重大風險，并解釋安全團隊應該怎樣做來提高人們的安全意識、保護現有企業軟件中的API，以及如何安全地使用API數據。

什么是API?

API是指一組函數或例程，它們用于完成特定任務或提供簡單方法來與軟件組件進行交互，通常允許自動化常見流程，例如與在其他機器上運行的服務器進行交互。

API可以是一個庫，其中包括例程、數據結構、對象類和變量的規格，或者只是暴露給API使用者的遠程調用的規格。一些API是基于國際標準(例如可移植操作系統接口，POSIX)，而另一些則是以開源或供應商文檔形式公之于眾。例如，微軟的Windows API讓開發人員能夠為Windows平臺創建軟件。

為了產生潛在收人來源和商業機會，企業正在越來越多地通過API來交付其業務應用程序和數據。此外，Web 2.0也推動了Web API使用量的激增，讓用戶與程序可以與在線應用程序背后的核心數據進行交互。亞馬遜云計算服務就是最好的例子，它使用API來讓用戶訪問其各種服務，例如EC2。

通過公開化API，企業可以提高合作伙伴連接性和云集成，并能夠更好地向客戶提供服務。同時，第三方也可以開發應用程序，為用戶提供額外的功能，并幫助提高企業服務和產品的知名度和部署率。

根據Layer 7 Technologies公司的最新研究顯示，超過43%的受訪者稱其企業目前已經部署了API計劃，而27%表示，在未來一年內將會推出這樣的計劃。Facebook平臺就是API取得成功的一個很好的例子;Facebook提供的API讓開發人員創建數百應用程序和服務，訪問Facebook及其用戶的數據，這無疑顯著推動了Facebook的發展和成功。

Web API(例如來自Facebook的API)通常是超文本傳輸協議請求消息，返回結構化響應消息，最常見的是可擴展標記語言或JavaScript對象符號格式。這種API快速取代了基于簡單對象訪問協議的Web服務和面向服務的架構;因為它們更容易部署，并且更適合創建一個開放架構，以在應用程序和用戶之間共享內容和數據。

API安全問題以及如何避免它們

除了諸多優點外，應用編程接口也存在安全問題，正如最近的安全泄露事故所顯示的。安全問題通常不在于API背后的概念，而在于它的編碼方式。很多應用開發人員在編寫或使用API時沒有考慮安全因素，使得應用和數據處于危險之中。當涉及API時，糟糕編寫的代碼很快就會變成危險代碼。

所幸的是，企業及其開發人員可以采取一些措施來加強和確保API在企業環境的安全性。

在開發過程(當然是在發布應用之前)中，安全專家應該手動檢查API代碼，以測試它是否可能被攻擊者濫用或誤用。文檔記錄也很關鍵，清楚記錄的代碼讓安全人員可以看到API應該以及不應該做什么，并讓整合API到應用的人了解如何正確部署API。

在文檔中，開發人員應該明確如何調用API、哪些數據將被返回以及以何種格式，還有可能出現什么錯誤消息。內部記錄還應該指明誰可以訪問API以及哪些信息將被記錄以確定哪些資源出于審計目的被誰在何時訪問。在訪問的話題上，在適當的時候，機器ID應補充身份驗證檢查。并且，還應該檢查每個API調用以確保用戶或設備有正確的權限來查看、編輯或刪除所需信息。然而，在用戶身份驗證后，很多開發人員通常省去了二次訪問控制檢查。

對于檢查API如何處理突發性輸入和請求，黑盒測試和模糊測試是關鍵。同樣重要的是，通過數據驗證例程來防止標準注入漏洞和跨站請求偽造攻擊，因為調用API可能來自不受信任的來源。此外，應該在所有類型的端點進行測試，而不只是對web瀏覽器。通過非瀏覽器應用(例如移動應用)訪問時，很多API未能部署SSL，所以一定要確保數據始終是加密狀態--當沒有要求純文本格式時。滲透測試和漏洞評估也應該側重于API，因為它們是應用的接入點。

試圖利用第三方的API的企業必須確保其開發人員完全了解如何安全地部署它們，并驗證所有來自這些API的響應。很多開發人員(無論是來自第三方還是內部開發人員)喜歡重復使用互聯網發現的代碼，特別是涉及如何調用特定API時。然而，復制和粘貼代碼，而不檢查它是否適合于特定內容，這是API相關漏洞進入應用的常見情況。

企業必須記住：雖然開發速度可能很重要，但對細節的注意也很重要。開發人員必須仔細閱讀API文檔，永遠不要依賴于互聯網上的道聽途說。企業的開發時間表應該給開發人員足夠的時間來了解如何正確地部署API，以及了解API可能帶來的潛在風險—特別是當涉及共享用戶數據時。糟糕編寫或部署的API可能引入攻擊向量，并增加了與機密性、完整性、可用性和可問責性的風險，因為它們是企業資源的網關。并且，企業應該盡可能地避免沒有開放的豐富文檔的API。如果加密密鑰被用作調用API的訪問和身份驗證機制，它們必須根據政策安全地存儲，永遠不要硬編碼到配置文件或其他腳本。

API的問題不太可能會很快消失;并且API正在成為現代開放企業的基石。鑒于其重要性，API應該得到創建和使用API的人的更多重視。如果安全地部署，API可以讓企業充分利用其自己和其他人的數據，同時確保便利性和安全性。如果部署不當，API可能被攻擊者利用來攻擊企業及其用戶。