最近一連串的 API 安全事件(Peloton,、Experian,、Clubhouse 等)無疑迫使許多安全和開發(fā)團(tuán)隊仔細(xì)檢查他們的 API 安全狀況,,以確保它們不會成為下一個被攻擊對象,。創(chuàng)建面向外部受眾的所有API的清單是組織在組合或重新評估API安全程序時最常見的出發(fā)點。有了這個清單,,下一步是評估每個暴露的 API 的潛在安全風(fēng)險,,比如弱身份驗證或以明文形式暴露敏感數(shù)據(jù)。
OWASP API安全Top 10為評估API清單的風(fēng)險類型提供了一個良好的框架,。它們被列在前10位是有原因的,,最常見和最嚴(yán)重的都排在前面。例如,,列表中的前兩個處理身份驗證和授權(quán),,這兩個都可以追溯到上面提到的一些最近的API事件,這在安全公司的客戶環(huán)境中很常見,。
未經(jīng)身份驗證的 API
未經(jīng)身份驗證的 API 是迄今為止在面向公眾的 API 中檢測到的最糟糕的事情,,對于處理基本業(yè)務(wù)信息的 API 尤其如此,這些信息可能包含遵守PCI或PHI法規(guī)的信息,。
在處理必要業(yè)務(wù)數(shù)據(jù)的面向公眾的 API 中缺乏身份驗證的一個常見原因是,,該 API 過去故意不進(jìn)行身份驗證,以支持不支持身份驗證的遺留應(yīng)用程序,。以前可能是這樣,,但這并不意味著API應(yīng)該保持開放。今天,,許多用戶(包括外部和內(nèi)部)將完全開放地訪問API,。了解舊限制歷史的人可能已經(jīng)離開了公司,因此,,企業(yè)現(xiàn)在需要努力填補這一差距,。為這些例外情況打開大門是絕對不能接受的,因為很少有人在以后的某個時間點再回去關(guān)閉大門,。
最佳實踐:永遠(yuǎn)不要部署未經(jīng)驗證的API,,無論是內(nèi)部的還是面向公眾的。
使用非空值身份驗證令牌的 API
盡管很難想象,,但通常會發(fā)現(xiàn) API 根本不使用 auth 令牌實現(xiàn)任何身份驗證,,而是僅檢查請求中是否存在一個。這個問題通常比 API 中缺少身份驗證更令人震驚,,因為這允許用戶僅通過在 API 請求中傳遞身份驗證令牌來訪問資源,。令牌的實際值并不重要,因為應(yīng)用程序僅檢查請求中是否存在身份驗證令牌(任何身份驗證令牌),。
很難想到用這種方法開發(fā) API 的充分理由,。也許他們?nèi)狈υ诤蠖藨?yīng)用程序中實現(xiàn)身份驗證邏輯所需的時間?不幸的是,,攻擊者無需花費太多精力或時間即可利用這些 API,。他們只需要為 auth 令牌發(fā)送一個非空值,API 請求就會被成功處理,。絕不應(yīng)允許使用非空值令牌,。曾經(jīng)。它帶來了“暫時”使用但永遠(yuǎn)不會被刪除的重大風(fēng)險,。
最佳實踐:始終為內(nèi)部或面向公眾的 API 分配令牌值,。
API經(jīng)過身份驗證,但未經(jīng)授權(quán)
只有身份驗證而沒有授權(quán)的 API 是另一個常見的漏洞,。部分原因是實現(xiàn)用戶身份驗證“足夠好”的概念,,通過驗證用戶的授權(quán)權(quán)限幾乎沒有什么好處。缺點是這允許用戶訪問不屬于他們的資源,。
例如,,假設(shè)一個用戶登錄來檢查他們的配置文件,而后端沒有強制執(zhí)行強授權(quán)檢查,。通過更改用戶標(biāo)識符,,用戶將能夠“嗅探”并通過相同的API獲取信息。在這種非常常見的API風(fēng)險中,,通過身份驗證的用戶可以通過簡單地枚舉標(biāo)識符來獲取許多其他用戶的信息,。
如果標(biāo)識符是簡單的數(shù)值,例如攻擊者可以輕松枚舉的 6 位數(shù)字,,則此問題會變得更糟,。最基本的建議是使用隨機生成的字母-數(shù)字標(biāo)識符,至少可以緩解(但不能消除)此類枚舉攻擊的風(fēng)險,。
最佳實踐:始終實施強授權(quán)機制來補充強身份驗證,。
API令牌擴散
應(yīng)用程序開發(fā)團(tuán)隊通常支持不同類型的身份驗證集成與其 API 的不同使用者,。這最終導(dǎo)致 API 的身份驗證方法分散,應(yīng)用程序所有者難以管理,。
例如,,消費者 A 可能會在請求標(biāo)頭中發(fā)送一個名為 X-api-token 的 API 令牌,以向應(yīng)用程序驗證自己的身份,。相反,,擁有相同API的消費者B可能會以一個名為API -key的請求參數(shù)發(fā)送他們的API令牌,第三個消費者C可能會在Authorization頭中發(fā)送他們的信息,。
這種不同的方法導(dǎo)致 API 以多種方式接受身份驗證令牌,,這些方法中的任何一個潛在漏洞,類似于我們上面看到的那些,,都可能危及所有這些方法的訪問,。我們的建議是強制API定義(如Swagger規(guī)范)的一致性,然后在發(fā)布之前對結(jié)果進(jìn)行測試以緩解風(fēng)險,。至少,,在運行時發(fā)現(xiàn)API 并檢測它們中是否存在這樣的碎片驗證問題是很重要的。
最佳實踐:使用 API 規(guī)范框架強制執(zhí)行一致性,,并使用基于功能的測試計劃超越基本的滲透測試,。
帶有不正確授權(quán)邏輯的API
具有不正確授權(quán)邏輯的 API 允許通過接受在低權(quán)限環(huán)境(例如 dev 或 staging)中生成的身份驗證令牌來訪問高權(quán)限環(huán)境,例如生產(chǎn)環(huán)境,。如果用戶可以輕松訪問生產(chǎn)環(huán)境中的敏感業(yè)務(wù)數(shù)據(jù),,這可能會迅速升級為一個重大漏洞。
精明的攻擊者可能能夠從較低的環(huán)境中獲取身份驗證令牌并將其重播到生產(chǎn)服務(wù)器,。身份驗證的糟糕實現(xiàn)將允許此類訪問,,因為身份驗證令牌本身可能是有效的,但適用于錯誤的環(huán)境,。為了修復(fù)這種風(fēng)險,,需要將 auth 令牌的授權(quán)范圍適當(dāng)限制在允許訪問的資源范圍內(nèi)。
最佳實踐:使用 OAuth Scopes 或其他工具來創(chuàng)建和實施設(shè)計良好的授權(quán)后端,。
總結(jié)
API 身份驗證令牌實際上是你的應(yīng)用程序中的關(guān)鍵,。這 5 個身份驗證漏洞都在客戶環(huán)境中發(fā)現(xiàn),使他們的 API 容易受到攻擊者入侵他們的應(yīng)用程序并泄露他們無權(quán)訪問的信息的攻擊,。
創(chuàng)建清單并分析面向公眾的 API 以在攻擊者發(fā)布或發(fā)現(xiàn)它們之前找到身份驗證漏洞非常重要,。