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

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

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

什么是API?

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

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

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

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

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

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

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

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

所幸的是，企業(yè)及其開發(fā)人員可以采取一些措施來加強和確保API在企業(yè)環(huán)境的安全性。

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

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

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

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

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

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