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的五個常見漏洞分別是什麼的詳細內容。更多資訊請關注PHP中文網其他相關文章！