[[420663]]

最近一連串的 API 安全事件(Peloton、Experian、Clubhouse 等)無(wú)疑迫使許多安全和開發(fā)團(tuán)隊(duì)仔細(xì)檢查他們的 API 安全狀況，以確保它們不會(huì)成為下一個(gè)被攻擊對(duì)象。創(chuàng)建面向外部受眾的所有API的清單是組織在組合或重新評(píng)估API安全程序時(shí)最常見的出發(fā)點(diǎn)。有了這個(gè)清單，下一步是評(píng)估每個(gè)暴露的 API 的潛在安全風(fēng)險(xiǎn)，比如弱身份驗(yàn)證或以明文形式暴露敏感數(shù)據(jù)。

OWASP API安全Top 10為評(píng)估API清單的風(fēng)險(xiǎn)類型提供了一個(gè)良好的框架。它們被列在前10位是有原因的，最常見和最嚴(yán)重的都排在前面。例如，列表中的前兩個(gè)處理身份驗(yàn)證和授權(quán)，這兩個(gè)都可以追溯到上面提到的一些最近的API事件，這在安全公司的客戶環(huán)境中很常見。

未經(jīng)身份驗(yàn)證的 API

未經(jīng)身份驗(yàn)證的 API 是迄今為止在面向公眾的 API 中檢測(cè)到的最糟糕的事情，對(duì)于處理基本業(yè)務(wù)信息的 API 尤其如此，這些信息可能包含遵守PCI或PHI法規(guī)的信息。

在處理必要業(yè)務(wù)數(shù)據(jù)的面向公眾的 API 中缺乏身份驗(yàn)證的一個(gè)常見原因是，該 API 過(guò)去故意不進(jìn)行身份驗(yàn)證，以支持不支持身份驗(yàn)證的遺留應(yīng)用程序。以前可能是這樣，但這并不意味著API應(yīng)該保持開放。今天，許多用戶(包括外部和內(nèi)部)將完全開放地訪問(wèn)API。了解舊限制歷史的人可能已經(jīng)離開了公司，因此，企業(yè)現(xiàn)在需要努力填補(bǔ)這一差距。為這些例外情況打開大門是絕對(duì)不能接受的，因?yàn)楹苌儆腥嗽谝院蟮哪硞€(gè)時(shí)間點(diǎn)再回去關(guān)閉大門。

最佳實(shí)踐：永遠(yuǎn)不要部署未經(jīng)驗(yàn)證的API，無(wú)論是內(nèi)部的還是面向公眾的。

使用非空值身份驗(yàn)證令牌的 API

盡管很難想象，但通常會(huì)發(fā)現(xiàn) API 根本不使用 auth 令牌實(shí)現(xiàn)任何身份驗(yàn)證，而是僅檢查請(qǐng)求中是否存在一個(gè)。這個(gè)問(wèn)題通常比 API 中缺少身份驗(yàn)證更令人震驚，因?yàn)檫@允許用戶僅通過(guò)在 API 請(qǐng)求中傳遞身份驗(yàn)證令牌來(lái)訪問(wèn)資源。令牌的實(shí)際值并不重要，因?yàn)閼?yīng)用程序僅檢查請(qǐng)求中是否存在身份驗(yàn)證令牌(任何身份驗(yàn)證令牌)。

很難想到用這種方法開發(fā) API 的充分理由。也許他們?nèi)狈υ诤蠖藨?yīng)用程序中實(shí)現(xiàn)身份驗(yàn)證邏輯所需的時(shí)間?不幸的是，攻擊者無(wú)需花費(fèi)太多精力或時(shí)間即可利用這些 API。他們只需要為 auth 令牌發(fā)送一個(gè)非空值，API 請(qǐng)求就會(huì)被成功處理。絕不應(yīng)允許使用非空值令牌。曾經(jīng)。它帶來(lái)了“暫時(shí)”使用但永遠(yuǎn)不會(huì)被刪除的重大風(fēng)險(xiǎn)。

最佳實(shí)踐：始終為內(nèi)部或面向公眾的 API 分配令牌值。

API經(jīng)過(guò)身份驗(yàn)證，但未經(jīng)授權(quán)

只有身份驗(yàn)證而沒(méi)有授權(quán)的 API 是另一個(gè)常見的漏洞。部分原因是實(shí)現(xiàn)用戶身份驗(yàn)證“足夠好”的概念，通過(guò)驗(yàn)證用戶的授權(quán)權(quán)限幾乎沒(méi)有什么好處。缺點(diǎn)是這允許用戶訪問(wèn)不屬于他們的資源。

例如，假設(shè)一個(gè)用戶登錄來(lái)檢查他們的配置文件，而后端沒(méi)有強(qiáng)制執(zhí)行強(qiáng)授權(quán)檢查。通過(guò)更改用戶標(biāo)識(shí)符，用戶將能夠“嗅探”并通過(guò)相同的API獲取信息。在這種非常常見的API風(fēng)險(xiǎn)中，通過(guò)身份驗(yàn)證的用戶可以通過(guò)簡(jiǎn)單地枚舉標(biāo)識(shí)符來(lái)獲取許多其他用戶的信息。

如果標(biāo)識(shí)符是簡(jiǎn)單的數(shù)值，例如攻擊者可以輕松枚舉的 6 位數(shù)字，則此問(wèn)題會(huì)變得更糟。最基本的建議是使用隨機(jī)生成的字母-數(shù)字標(biāo)識(shí)符，至少可以緩解(但不能消除)此類枚舉攻擊的風(fēng)險(xiǎn)。

最佳實(shí)踐：始終實(shí)施強(qiáng)授權(quán)機(jī)制來(lái)補(bǔ)充強(qiáng)身份驗(yàn)證。

API令牌擴(kuò)散

應(yīng)用程序開發(fā)團(tuán)隊(duì)通常支持不同類型的身份驗(yàn)證集成與其 API 的不同使用者。這最終導(dǎo)致 API 的身份驗(yàn)證方法分散，應(yīng)用程序所有者難以管理。

例如，消費(fèi)者 A 可能會(huì)在請(qǐng)求標(biāo)頭中發(fā)送一個(gè)名為 X-api-token 的 API 令牌，以向應(yīng)用程序驗(yàn)證自己的身份。相反，擁有相同API的消費(fèi)者B可能會(huì)以一個(gè)名為API -key的請(qǐng)求參數(shù)發(fā)送他們的API令牌，第三個(gè)消費(fèi)者C可能會(huì)在Authorization頭中發(fā)送他們的信息。

這種不同的方法導(dǎo)致 API 以多種方式接受身份驗(yàn)證令牌，這些方法中的任何一個(gè)潛在漏洞，類似于我們上面看到的那些，都可能危及所有這些方法的訪問(wèn)。我們的建議是強(qiáng)制API定義(如Swagger規(guī)范)的一致性，然后在發(fā)布之前對(duì)結(jié)果進(jìn)行測(cè)試以緩解風(fēng)險(xiǎn)。至少，在運(yùn)行時(shí)發(fā)現(xiàn)API 并檢測(cè)它們中是否存在這樣的碎片驗(yàn)證問(wèn)題是很重要的。

最佳實(shí)踐：使用 API 規(guī)范框架強(qiáng)制執(zhí)行一致性，并使用基于功能的測(cè)試計(jì)劃超越基本的滲透測(cè)試。

帶有不正確授權(quán)邏輯的API

具有不正確授權(quán)邏輯的 API 允許通過(guò)接受在低權(quán)限環(huán)境(例如 dev 或 staging)中生成的身份驗(yàn)證令牌來(lái)訪問(wèn)高權(quán)限環(huán)境，例如生產(chǎn)環(huán)境。如果用戶可以輕松訪問(wèn)生產(chǎn)環(huán)境中的敏感業(yè)務(wù)數(shù)據(jù)，這可能會(huì)迅速升級(jí)為一個(gè)重大漏洞。

精明的攻擊者可能能夠從較低的環(huán)境中獲取身份驗(yàn)證令牌并將其重播到生產(chǎn)服務(wù)器。身份驗(yàn)證的糟糕實(shí)現(xiàn)將允許此類訪問(wèn)，因?yàn)樯矸蒡?yàn)證令牌本身可能是有效的，但適用于錯(cuò)誤的環(huán)境。為了修復(fù)這種風(fēng)險(xiǎn)，需要將 auth 令牌的授權(quán)范圍適當(dāng)限制在允許訪問(wèn)的資源范圍內(nèi)。

最佳實(shí)踐：使用 OAuth Scopes 或其他工具來(lái)創(chuàng)建和實(shí)施設(shè)計(jì)良好的授權(quán)后端。

總結(jié)

API 身份驗(yàn)證令牌實(shí)際上是你的應(yīng)用程序中的關(guān)鍵。這 5 個(gè)身份驗(yàn)證漏洞都在客戶環(huán)境中發(fā)現(xiàn)，使他們的 API 容易受到攻擊者入侵他們的應(yīng)用程序并泄露他們無(wú)權(quán)訪問(wèn)的信息的攻擊。

創(chuàng)建清單并分析面向公眾的 API 以在攻擊者發(fā)布或發(fā)現(xiàn)它們之前找到身份驗(yàn)證漏洞非常重要。

本文翻譯自：https://securityboulevard.com/2021/07/api-security-need-to-know-top-5-authentication-pitfalls/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+SecurityBloggersNetwork+%28Security+Bloggers+Network%29如若轉(zhuǎn)載，請(qǐng)注明原文地址。