API的五個常見漏洞

點擊藍字關註我們

安全牛評

API讓天下沒有難做的生意，駭客也是這麼認為的。在企業數字化轉型如火如荼的今天，API已經遠遠超出了技術范疇，互聯網商業創新和傳統企業數字化轉型都離不開API經濟或者API戰略。API連接的不僅僅是系統和數據，還包括企業職能部門、客戶和合作夥伴，甚至整個商業生態。與此同時，日益嚴格的安全威脅，使得API正在成為網路安全的下一個前沿陣地。本文，我們整理了安全專家們給企業提出的五大API安全弱點和修補建議。

API使一切都變得更加容易，從數據共享到系統連接到關鍵功能的交付，但API也使攻擊者（包括惡意機器人）更容易進行攻擊。API的應用激增，正刺激網路犯罪分子越來越多地利用API安全漏洞進行訛詐和竊取數據。

以下，我們將探討容易被駭客利用的五個API漏洞，並分享安全專家們給出的緩解和強化建議。

一、太容易被發現

假如你是駭客，準備攻擊一家企業，那麼首先要做的第一件事就是識別盡可能多的API。我首先按常規方式使用目標應用程序，在瀏覽器中打開Web應用程序或者在手機端下載安裝移動應用程序，然後使用攔截代理監視通訊。

攔截代理能夠捕獲瀏覽器或移動應用程序對後端Web服務器發出的所有請求，從而使攻擊者可以對所有可用的API端點進行分類。例如，大多數API都將API/V1/login作為身份驗證端點。

如果目標也是移動應用程序，則將應用程序包拆開，並查看應用程序內部可用的API調用。考慮到所有可能的活動，攻擊者可以搜索無法正確保護用戶數據的常見配置錯誤或API。

最後，攻擊者尋找API文檔。一些組織為第三方發布API文檔，但為所有用戶使用相同的API端點。

有了一個不錯的端點清單，攻擊者就可以測試標準用戶行為和異常行為測試，可以通過兩種方法找到有趣的漏洞。

解決方法：為了使攻擊者更加難以發現API，請確保通過僅允許有效用戶拜訪的權限管理來控制對API文檔的拜訪。雖然將證書固定在移動應用程序上並不能完全隱藏API端點，並且也不完美，但確實給攻擊增加了額外的步驟。對Web服務器的API請求應盡可能地被混淆和控制。

二、過於詳細的錯誤資訊

最近，攻擊者接管帳戶的嘗試在不斷增加。錯誤消息過於「詳細周到」，往往使此類攻擊更加容易。冗長的錯誤消息會引導攻擊者了解他們需要進行哪些更改才能偽裝成合法請求。API專為低負載下的高速交易而設計，使攻擊者可以使用高性能系統找出有效帳戶，然後嘗試登錄並更改密碼進行利用。

解決方法：不要拿用戶體驗作為擋箭牌，有些看起來有利於用戶體驗的做法，未必有利於安全性。系統返回的錯誤資訊不應該包括錯誤的用戶名或錯誤的密碼，甚至不能包含錯誤資訊的類別（用戶名還是密碼錯誤）。用於查詢數據的錯誤消息也是如此，如果查詢/搜索格式不正確或由於某種原因而無法執行，則應該返回最「沒有營養」的錯誤資訊：「糟糕，哪裡出錯了」。

三、參數太多

當攻擊者通過API調用遍歷攻擊系統時，他們必須弄清楚可以發送些什麼來獲取數據。攻擊者「信奉」這樣的一個事實：即越龐雜的系統，出錯的地方越多。攻擊者識別出API後，他們將對參數進行分類，然後嘗試拜訪管理員（垂直特權升級）或另一個用戶（水平特權升級）的數據以收集其他數據。通常，太多不必要的參數被暴露給了用戶。

在最近的研究項目中，我們對目標服務的API調用返回了大量數據，很多都是不必要的數據資訊，例如付款網關的處理器密鑰和可用的折扣資訊等。這些「獎勵資訊」使攻擊者可以更好地理解這些API調用的上下文和語法。攻擊者不需要太多的想像力就能弄清楚下一步該怎麼做。這些額外的參數為攻擊者提供了豐富的攻擊數據集。

解決方法：如果將用戶看到的內容範圍限制為必需內容，限制關鍵數據的傳輸，並使數據查詢結構未知，那麼攻擊者就很難對他們知道的參數進行暴力破解。

四、數據過多

同樣地，由於可用的參數太多，收集數據將成為顯而易見的下一步行動。許多企業的系統支持匿名連接，並且傾向泄漏普通用戶不需要的額外數據。另外，許多企業傾向於存儲可以直接拜訪的數據。

安全專業人員正在努力應對API請求經常暴露數據存儲位置的挑戰。例如，當我查看安全照相機中的視訊時，可以看到該資訊來自Amazon S3存儲庫。通常，那些S3存儲庫的保護並不周全，任何人的數據都可以被檢索。

另一個常見的數據挑戰是數據過載，很多企業都像入冬前的花栗鼠，存儲的數據量遠遠超出了需要。很多過期客戶數據已經沒有商業價值和保存價值，但是如果發生泄露，則會給企業帶來巨大的品牌和合規風險。

解決方法：對於存儲用戶數據的企業，不僅僅是PII或PHI，都必須進行徹底的數據審查。在檢查了存儲的數據之後，應制定數據拜訪規則並進行測試。確保能夠匿名拜訪的數據不涉及任何敏感數據。

五、安全設計太少

多年以來，應用程序設計總是優先考慮功能性和可用性，很少考慮安全性。很多CISO表示，API安全性尤其不被重視，甚至完全被排除在安全設計流程之外。通常都是開發人員開發和部署完成後，在API投入生產且頻繁遭受攻擊後才亡羊補牢查找問題。安全性（包括API安全性）需要成為產品設計的一部分，並且應作為首要考慮因素之一加以實現，而不是事後填坑。

解決方法：審查應用程序的安全體系結構是邁向安全系統的重要第一步。請記住，API使攻擊者能更高效地攻擊或利用您的系統。設計安全性的目標是讓API成為用戶而非攻擊者的高效工具。

以上隻列舉了一些常見的API漏洞，總之，最重要的是在軟體開發生命周期的早期階段就討論安全問題。微小的改進就可以帶來巨大的好處，避免API遭攻擊造成的巨大財務和品牌損失。