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

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

　　我們將在本文中介紹五種真實的身份驗證繞過技術。

　　技術1——刷新令牌終端配置錯誤

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

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

　　技術2 ——SSO配置不正確

　　大多數(shù)應用程序都使用SSO系統(tǒng)，因為與處理許多身份驗證門戶相比，SSO系統(tǒng)更容易安全管理。但是簡單地使用SSO并不能自動保護系統(tǒng)，因為SSO的配置也應得到保護。

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

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

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

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

　　技術3——基于CMS的訪問漏洞

　　內(nèi)容管理系統(tǒng)(CMS)，如WordPress、Drupal和Hubspot也需要進行安全配置，以免它們在使用中中引入漏洞。

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

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

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

　　技術4 ——JWT令牌的使用

　　JWT令牌或JSON web令牌，在新的web應用程序中很流行。但是，雖然它們默認具有安全機制，但后端服務器配置也應該是安全的。

　　我的一項任務是在他們的內(nèi)部應用程序中使用SSO身份驗證。當直接訪問時，應用程序將用戶重定向到Microsoft SSO web頁面。到目前為止，一切順利。

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

　　在通用值內(nèi)：

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

　　技術5——將身份驗證類型更改為Null

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

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

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

　　總結

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