攻擊者知道在針對API時如何避開WAF和API網關。以下是一些公司應對API攻擊快速增長的示例。

5月初，Pen Test Partners 安全研究員 Jan Masters 發現，他竟然能夠在未經身份驗證的情況下，向Peloton的官方API提出可獲取其它用戶私人數據的請求，且用戶的本地設備和云端服務器都如此不設防。

這些數據中包括了詳細的用戶年齡、性別、城市、體重、鍛煉統計數據，甚至可揭示用戶在個人資料設置頁面中設為私密的生日等信息。

應用程序編程接口（API）允許輕松地機器對機器通信。如今，應用程序開發中的API使用已成為新的實踐標準，通過集成第三方服務的功能，開發人員不用再從無到有自己構建所有功能，這樣一來可以加快新產品及服務的開發過程。

近年來，API的使用更是呈現爆炸式增長。根據Akamai的說法，API通信現在占所有互聯網流量的83％以上。

盡管API支撐著用戶早已習慣的互動式數字體驗，是公司數字化轉型的基礎，但它們同時也為惡意黑客提供了訪問公司數據的多種途徑，成為諸多安全問題的根源所在。

除Peloton公司外，最近新聞中曝光的涉及API相關網絡安全問題的企業還包括Equifax、Instagram、Facebook、亞馬遜以及Paypal。

API的應用以及不斷攀升的攻擊趨勢

根據Salt Security于今年2月發布的報告顯示，去年有91％的公司存在與API相關的安全問題。其中，最常見的是漏洞，涉及54%的受訪組織；緊隨其后的是身份驗證問題（46%受訪者）、僵尸程序（20%受訪者）以及拒絕服務（19%受訪者）。

80％的組織認為他們的安全工具不能有效地防止API攻擊。此外，Salt Security的調查還發現，三分之二的組織由于與API安全相關的擔憂而減緩了將新應用程序投入生產的速度。即便是擁有Web應用程序防火墻（WAF）和API網關的所有Salt客戶，每個月也都要經歷多次API攻擊，這就意味著這些安全工具已經阻止不了API攻擊。

實際上，根據Salt的說法，WAF和API甚至已經阻擋不住OWASP API安全Top10威脅中90%的因素。

但糟糕的現實是，超過四分之一的組織正在沒有任何安全策略的情況下運行基于關鍵API的關鍵應用程序。例如，Peloton最初就是可供任何人在任何地方通過API訪問用戶數據，而無需任何身份驗證。

API存在漏洞并不稀奇。根據Salt Security的報告，82％的組織對了解API詳細信息缺乏信心，例如API是否包含個人身份信息（PII），如客戶專有網絡信息、受保護的健康信息以及持卡人數據等；而22％的組織表示他們無法知道哪些API公開了敏感數據。

Traceable公司安全研究工程師Roshan Piyush表示，Peloton的錯誤是使用了未經身份驗證的API，而其他遇到相同問題的公司還包括Panera、Fiserv、LifeLock和Kay Jewelers。可以說，這樣的案例舉不勝舉，歸納來說，就是在開發過程中忽視了對API的身份驗證和授權保護等問題。

一家銀行API應用增長的故事

一家中型金融機構的網絡安全技術經理Jeff Serota表示，在過去的幾個月中，他的公司對API的使用急劇增長。如今，API連接了大約3,000個端點，其中包括內部應用程序、屬于業務合作伙伴的應用程序以及面向客戶的網站和移動設備。

不過這僅僅只是開始，按照公司的發展規劃，未來三年API應用還將迅速增加。他們的目標是消除所有本地數據中心，并遷移至適用于所有內容的Web服務和API。

Serota介紹稱，其API調用通過四個主要URL，不同的服務在其API調用中包含不同的參數。這種方法創建了一個保護層。他說，由于使用API存在很多風險，所以我們實際上混淆了一些API端點名稱，以使其更難被橫向攻擊或被發現并用于惡意目的。

在過去的六個月中，該機構還一直在將多個API網關整合到一個主要網關中。而對于API網關，該公司選擇了Apigee，這是google在2016年收購的API安全供應商。

一些公司在嘗試讓所有開發人員都擁有一個網關時遇到了問題，或是擔心潛在的瓶頸、單點故障或DDoS攻擊。但Serota表示，他們的公司并不存在這種情況。相反地，他們的開發人員更喜歡API網關方法，因為作為基于SaaS和多區域的服務，API實際上為他們提供了更好的可用性和更低的延遲。

例如，一個API預計每月將有1000萬筆交易，但在啟動后的頭兩周內就發生了2億筆交易。而他們并沒有感到任何延遲或性能下降。Serota稱，目前，在他們的生產環境中，每月有大約20億次API調用，而兩年前約為8億次。

對于身份驗證，該公司的移動和基于Web的應用程序使用了較舊的JAVA技術，但他們正在使用軟件開發套件將其全部轉移到基于API的身份驗證中。而對于外部合作伙伴，該公司也正在努力為其API調用建立零信任模型。

以前，對于通過自己的Web或移動應用程序訪問該機構的消費者，會存在持久性，這就意味著消費者不需要多次進行身份驗證過程。而該公司的零信任模型意味著不再允許任何類型的會話持久性以及任何類型的cookie。用戶必須每次都要重新認證。就“安全”“方便”和“快速”三個要求而言，你可以同時擁有兩個，但沒辦法全部都實現。

對于位于公司安全范圍內的API，還有另一種方法。Serota介紹稱，在公司內部，我們更傾向于使用輕量級的零信任以外的方法。目前，我們正在使用IP安全性，根據要進行的操作，服務將進行身份驗證，并執行更多基于Active Directory的操作。

行為分析還可以用來檢測內部和外部流量的可疑行為，并自動過濾明顯的不良消息。Serota稱，我們會使用所有內容——從IP信譽到行為分析再到用戶和賬戶模式等，來分析任何可疑行為。例如，我們有一個用戶每隔一個周五會存入200美元存款，而現在每個周三都會存入800美元。這時候就會引起我們的注意。這不僅是為了保護我們的資產，也是確保我們主動報告了可能存在“洗錢”或“人口販賣”的情況。

Serota還表示，通過使用自動化，該公司能夠將到達其網絡運營中心和網絡安全事件響應團隊的問題數量減少35％，出現在他們身上的誤報變得越來越少。

機器人（Bot）對API的攻擊

API流量不斷增長，但惡意API流量卻增長得更快。 數據顯示，Salt Security客戶每月的API調用量增長了51％，而惡意流量則增長了211％。

根據Akamai對來自金融服務、零售、媒體和娛樂行業的100個企業客戶一個月的API數據進行的分析發現，在總數7440億個API調用中，有12%來自已知的惡意行為者；25%來自既非web瀏覽器又非移動設備或應用程序的終端客戶，這就意味著它們可能來自惡意行為者，而非合法用戶。

安永（Ernst＆Young）網絡安全董事總經理Rishi Pande表示，傳統的前端應用程序（網站和移動應用程序）具有針對攻擊者的保護措施，其中包括針對DDoS、憑據填充和其他自動攻擊的防御。不過，縱然前端受到保護，但如果API網關不受保護的話，同樣會危及前端安全。

API正在迅速發展，一些企業認為他們的技術可以提供適當的保護，而實際上這些工具本身還沒有準備好應對挑戰。

實際上，針對API層的攻擊正越來越受到黑客的歡迎，因為它更加匿名，而且API的保護程度通常不及網站和移動應用程序。甚至可以說，如今的API安全性就如同應用程序安全性在2009年的發展水平。

一旦攻擊者分解了一個移動應用程序并弄清楚了它的通信方式，他們就可以使用相同的API通道發送請求。人工智能和機器學習可以幫助抵御這種情況，因為通過機器人發出的API請求看起來與使用合法應用程序的真實人類發出的請求不同。

是時候解決孤島問題了

根據Postman的《2020年API狀態報告》，該報告對13,500多名開發人員進行了調查，結果顯示只有36％的公司對其API進行了安全性測試。相比之下，進行功能測試的公司占70％，而進行集成測試的公司則占67％。

而根據SmartBear的《2020年API狀態報告》顯示，可用性是開發人員對API的最大關注，其次是功能，再次才是安全性。

造成這種問題的部分原因在于，開發團隊與安全團隊，以及安全團隊與網絡和基礎架構團隊間彼此孤軍作戰，缺乏充分的溝通和合作。而孤島問題的解決方案就是DevSecOps。現在，我們可以集成測試并將測試控制權交給應用程序開發人員。我們要使每個人都成為安全團隊的成員。

從一開始就將安全性納入應用程序開發流程，要比嘗試使用API網關之類的技術來保護事物更為重要。公司應該專注于更好的體系結構、更好的安全性和更好的API調用。這樣做可能需要很長的時間，但是想要獲得更好的保護就必須開發出更安全的應用程序。只有應用程序足夠強大以抵御攻擊，我們才不需要其他元素來提供額外的安全性。

如今，通過DevSec團隊協作，開發人員開始對安全性有了更多的了解。不過，在API安全方面仍然存在諸多問題。首先就是業務邏輯問題，這是應用程序安全性的其中一個關鍵方面。隨著將monolithic應用程序分解為通過API連接的小型服務，發現并緩解邏輯問題的挑戰被放大了。該應用程序可以完全按照其設計的方式運行，身份驗證機制也可以完全安全，它可以完全擺脫漏洞，但是如果編碼中存在問題，則仍然可能發生違規行為。

然后要注意的是標準漏洞集。2019年發布的OWASP API Top 10威脅在過去兩年中沒有發生變化，這說明我們正在重復遭遇同樣的問題。

最后，由于缺乏足夠的人員手動監視API安全，因此組織需要研究工具、自動化、掃描技術和遙測監視，以確定API的調用方式，并尋找出可能表明惡意濫用的異常行為。

倉儲物流企業獲得API安全可見性

開發人員啟動Web服務和設置API變得比以往任何時候都更加容易。不過，與任何其他新技術一樣，安全性也經常滯后。

盡管開發人員都在使用新的安全控制，但仍然可能存在老舊的系統。這些過時的僵尸API帶來了巨大的安全風險，此外，那些原計劃只做短期使用卻未及時退役的API也會帶來很大的風險。

倉儲物流公司Prologis的安全主管Tyler Warren表示，我們無法保護自己并不知道的東西！我們必須清楚地知道自己擁有什么才能保護它，這是頭等大事。

如今，Prologis已在全球19個國家/地區擁有近10億平方英尺的面積，約5,000個倉庫。當人們聽到Prologis是一家倉庫公司時，往往會質疑“你們怎么可能正在研發高科技？”但是，Prologis高管層清楚地明白，技術是業務的推動者，而不是成本中心。所以，早在4年前，該公司就開始開發面向客戶的系統。

現在，有了基于云的Prologis Essentials平臺，客戶可以隨時提交服務票證或檢查票證的狀態，更重要的是，當有人搬進新倉庫時，可以與提供蟲害控制、叉車、照明以及其他所需產品和服務的本地供應商聯系。

Warren介紹稱，Prologis Essentials幾乎完全是無服務器的，主要依賴Amazon和lambda函數，所以無需處理任何的遺留系統問題。該平臺使用AWS API網關，并且有約15個API服務于500個端點，其中包括內部連接以及與外部業務合作伙伴的集成。上個月，該系統處理了529,000個API請求。

但是Warren發現，AWS并未提供有關API可視化的大量信息。為了解決這一問題，Warren團隊嘗試了很多方法，但都不如人意。他們致力于尋找一種易于部署且不會妨礙開發團隊的技術。最終，Prologis選擇了Salt Security解決方案。

他們原本計劃2021年再將Essentials系統集成到Salt Security中，但是最終還是將計劃提前了。原因在于API攻擊面正在吸引越來越多的關注，惡意行為者也發現了很多攻擊面，他們沒有時間去冒險。

最終，將Essentials系統集成到Salt Security的工作花費了大約一個月的時間，因為許多方面都必須經過不斷地測試，并確保開發人員對結果滿意且保證不影響性能。

該工具位于AWS環境中，并在API網關處偵聽流量、獲取日志和元數據，并將報告發送到Salt的SaaS儀表板以進行警報和報告，這使得Prologis獲得了很好的API安全可見性。

該系統已于去年秋天啟動并運行。它可以連接到WAF并自動觸發動作，可以發送報告供安全人員手動查看，還可以查找潛在的PII泄漏。此外，該系統還捕獲到了一些情況，例如API提供了許多并非必要的信息，這一點是許多企業在使用API時必須注意的問題。記住，如非必要，那就不要做！