身份驗(yàn)證繞過漏洞是現(xiàn)代web應(yīng)用程序中普遍存在的漏洞，也是隱藏最深很難被發(fā)現(xiàn)的漏洞。

　　為此安全防護(hù)人員不斷在開發(fā)新的認(rèn)證方法，保障組織的網(wǎng)絡(luò)安全。盡管單點(diǎn)登錄(SSO)等工具通常是對(duì)舊的登錄用戶方式的改進(jìn)，但這些技術(shù)仍然可能包含嚴(yán)重的漏洞。無論是業(yè)務(wù)邏輯錯(cuò)誤還是其他軟件漏洞，都需要專業(yè)人員來分析其中的復(fù)雜性。

　　我們將在本文中介紹五種真實(shí)的身份驗(yàn)證繞過技術(shù)。

　　技術(shù)1——刷新令牌終端配置錯(cuò)誤

　　在這種情況下，一旦用戶使用有效憑證登錄到應(yīng)用程序，它就會(huì)創(chuàng)建一個(gè)在應(yīng)用程序其他地方使用的承載身份驗(yàn)證令牌。該認(rèn)證令牌在一段時(shí)間后過期。就在過期之前，應(yīng)用程序在終端/refresh/tokenlogin中向后端服務(wù)器發(fā)送了一個(gè)請(qǐng)求，該請(qǐng)求在標(biāo)頭和HTTP主體部分的用戶名參數(shù)中包含有效的身份驗(yàn)證令牌。

　　進(jìn)一步的測(cè)試表明，刪除請(qǐng)求上的Authorization標(biāo)頭并更改HTTP主體上的用戶名參數(shù)將為提供的用戶名創(chuàng)建一個(gè)新的有效令牌。利用此漏洞，擁有匿名配置文件的攻擊者可以通過提供用戶名為任何用戶生成身份驗(yàn)證令牌。

　　技術(shù)2 ——SSO配置不正確

　　大多數(shù)應(yīng)用程序都使用SSO系統(tǒng)，因?yàn)榕c處理許多身份驗(yàn)證門戶相比，SSO系統(tǒng)更容易安全管理。但是簡(jiǎn)單地使用SSO并不能自動(dòng)保護(hù)系統(tǒng)，因?yàn)镾SO的配置也應(yīng)得到保護(hù)。

　　現(xiàn)在，一個(gè)應(yīng)用程序使用Microsoft SSO系統(tǒng)進(jìn)行身份驗(yàn)證。當(dāng)訪問internal.redacted.com URL時(shí)，web瀏覽器會(huì)重定向到單點(diǎn)登錄系統(tǒng)：

　　乍一看，它似乎是安全的，但對(duì)后端請(qǐng)求的分析顯示，應(yīng)用程序在重定向響應(yīng)上返回了異常大的內(nèi)容長(zhǎng)度(超過40000字節(jié))

　　為什么應(yīng)用程序要這樣做呢?當(dāng)然是配置錯(cuò)誤。在將用戶發(fā)送到SSO的重定向時(shí)，應(yīng)用程序向每個(gè)請(qǐng)求泄露了其內(nèi)部響應(yīng)。因此，可以篡改響應(yīng)，將302 Found頭更改為200 OK，并刪除整個(gè)Location標(biāo)頭，從而獲得對(duì)整個(gè)應(yīng)用程序的訪問。

　　此外，可以通過在Burp Suite中添加Match & Replace規(guī)則來自動(dòng)刪除標(biāo)題并自動(dòng)更改值，從而實(shí)現(xiàn)這個(gè)過程的自動(dòng)化。

　　技術(shù)3——基于CMS的訪問漏洞

　　內(nèi)容管理系統(tǒng)(CMS)，如WordPress、Drupal和Hubspot也需要進(jìn)行安全配置，以免它們?cè)谑褂弥兄幸肼┒础?/p>

　　在發(fā)現(xiàn)的一個(gè)示例中，在一個(gè)內(nèi)部應(yīng)用程序中使用了一個(gè)流行的CMS平臺(tái)Liferay。該應(yīng)用程序只有一個(gè)不需要身份驗(yàn)證就可以訪問的登錄頁(yè)面，所有其他頁(yè)面都在應(yīng)用程序UI中受到限制。

　　對(duì)于那些不熟悉Liferay的人來說，CMS為應(yīng)用程序工作流使用了portlet，它的參數(shù)是數(shù)字中的p_p_id。對(duì)于該應(yīng)用程序，可以通過將參數(shù)值更改為58來訪問登錄portlet。在正常的登錄頁(yè)面中，只有登錄表單是可訪問的。然而，通過直接訪問portlet，可以達(dá)到Create Account功能，然后在不需要適當(dāng)?shù)氖跈?quán)情況下就可以進(jìn)行自注冊(cè)并訪問內(nèi)部應(yīng)用程序。

　　請(qǐng)注意，雖然Liferay以前使用過這個(gè)工作流，但它的最新版本使用了portlet名稱而不是數(shù)字ID。不過，也可以通過更改名稱來訪問其他portlet。

　　技術(shù)4 ——JWT令牌的使用

　　JWT令牌或JSON web令牌，在新的web應(yīng)用程序中很流行。但是，雖然它們默認(rèn)具有安全機(jī)制，但后端服務(wù)器配置也應(yīng)該是安全的。

　　我的一項(xiàng)任務(wù)是在他們的內(nèi)部應(yīng)用程序中使用SSO身份驗(yàn)證。當(dāng)直接訪問時(shí)，應(yīng)用程序?qū)⒂脩糁囟ㄏ虻組icrosoft SSO web頁(yè)面。到目前為止，一切順利。

　　然而，一些JS文件不需要身份驗(yàn)證就可以訪問。測(cè)試顯示，該應(yīng)用程序使用了安全登錄后通過Microsoft SSO系統(tǒng)發(fā)送的JWT令牌。在后端機(jī)制上，存在一個(gè)安全錯(cuò)誤配置，即不檢查是否為特定的應(yīng)用程序生成了JWT令牌。相反，它接受任何具有有效簽名的JWT令牌。因此，使用來自微軟網(wǎng)站的JWT令牌示例如下：

　　在通用值內(nèi)：

　　有可能訪問內(nèi)部終端，泄露公司數(shù)據(jù)。

　　技術(shù)5——將身份驗(yàn)證類型更改為Null

　　在此情況中，應(yīng)用程序通過 base64 編碼的 XML 請(qǐng)求向 HTTP 發(fā)布數(shù)據(jù)上發(fā)送所有請(qǐng)求。在登錄機(jī)制上，它將用戶名作為參數(shù)別名發(fā)送，將密碼作為scode發(fā)送。scode 參數(shù)內(nèi)的值已進(jìn)行哈希處理。分析顯示，它使用了所提供密碼值的 md5 值。請(qǐng)求中還有另一個(gè)有趣的標(biāo)志：scode 有一個(gè)屬性，其類型值為 2。

　　我嘗試將該值賦值為1，它將接受明文密碼。成功了!因此，在明文值中使用暴力攻擊中是可能的。沒什么大不了的，但這標(biāo)志著我走對(duì)了路。把它賦值給空值怎么樣?或者其他值，如-1、0或9999999999?大多數(shù)都返回了除0之外的錯(cuò)誤代碼。我用屬性0做了幾次嘗試，但沒有成功，直到我將密碼值作為空值發(fā)送出去。

　　我意識(shí)到只需提供用戶名和密碼即可訪問任何帳戶。事實(shí)證明，這是一個(gè)很大的錯(cuò)誤。

　　總結(jié)

　　復(fù)雜的身份驗(yàn)證機(jī)制可能成為攻擊者使用的最具隱蔽性的攻擊手段，特別是在容易出現(xiàn)業(yè)務(wù)邏輯漏洞的應(yīng)用程序上。因?yàn)樽詣?dòng)掃描器大多無法進(jìn)入這類漏洞，所以仍然需要手工來找到它們。鑒于現(xiàn)代軟件環(huán)境的復(fù)雜性，沒有任何一個(gè)安全研究人員能夠發(fā)現(xiàn)所有可能的漏洞或攻擊載體。