研究人員警告說，由于16個不同的URL解析庫之間的不一致而導致的8個不同的安全漏洞，可能導致多種Web應用程序中的拒絕服務(DoS)情況、信息泄漏和遠程代碼執行(RCE)。

這些漏洞是在為各種語言編寫的第三方Web包中發現的，并且像Log4Shell和其他軟件供應鏈威脅一樣，可能已被導入到數百或數千個不同的Web應用程序和項目中。受影響的是Flask(一個用Python編寫的微型Web框架)、Video.js(HTML5視頻播放器)、Belledonne(免費的VoIP和IP視頻電話)、Nagios XI(網絡和服務器監控)和Clearance(Ruby密碼驗證)。

跳至問題概要。

理解URL解析混亂

URL解析是將Web地址分解為其底層組件的過程，以便正確地將流量路由到不同的鏈接或不同的服務器。可用于各種編程語言的URL解析庫通常被導入到應用程序中以實現此功能。

來自Claroty Team82研究部門和Synk的研究人員在周一的一份分析報告中寫道：“URL實際上是由五個不同的組件構成的：方案、權限、路徑、查詢和片段。”“每個組件都扮演著不同的角色，它決定了請求的協議、持有資源的主機、應該獲取的確切資源等等。”

根據綜合分析，由于每個庫進行解析活動的方式不同，安全漏洞會突然出現。

Team82和Synk研究了16個不同的URL解析庫，包括：urllib(Python)、urllib3(Python)、rfc3986(Python)、httptools(Python)、curl lib(cURL)、Wget、Chrome(Browser)、Uri(.NET)、URL(Java)、URI(Java)、parse_url(PHP)、url(NodeJS)、url-parse(NodeJS)、net/url(Go)、uri(Ruby)和URI(Perl)。

他們在這些庫解析組件的方式中發現了五類不一致：

• Scheme混淆：涉及丟失或Scheme格式錯誤的URL的混淆
• 斜杠混淆：包含不規則斜杠數量的URL混淆
• 反斜杠混淆：涉及包含反斜杠(\)的URL混淆
• URL編碼數據混淆：涉及包含URL編碼數據的URL混淆
• Scheme Mix-ups：涉及在沒有特定Scheme解析器的情況下解析屬于某個Scheme的URL混淆

根據報告，問題在于，由于兩個主要的Web應用程序開發漏洞，這些不一致可能會產生易受攻擊的代碼塊：

• 使用多個解析器：無論是出于設計還是疏忽，開發人員有時會在項目中使用多個URL解析庫。由于某些庫可能會以不同方式解析相同的URL，因此可能會在代碼中引入漏洞。
• 規范不兼容：不同的解析庫是根據不同的Web標準或URL規范編寫的，這在設計上造成了不一致，這也會導致漏洞，因為開發人員可能不熟悉URL規范之間的差異及其含義(例如，應該檢查或清理的內容)。

作為真實攻擊場景的示例，斜線混淆可能導致服務器端請求偽造(SSRF)漏洞，這可用于實現RCE。研究人員解釋說，不同的庫以不同的方式處理斜杠數量超過通常數量的URL(例如https:///www.google.com)：其中一些會忽略多余的斜杠，而另一些則將URL解釋為沒有主機。

對于前者(大多數現代瀏覽器和cURL都采用這種方法)，接受格式錯誤、斜杠數量不正確的URL可能導致SSRF，研究人員解釋說：“[不]忽略額外斜杠的庫......將解析這個[格式錯誤]URL作為具有空權限(netloc)的URL，因此通過了對netloc(在本例中為空字符串)與google.com進行比較的安全檢查。但是，由于cURL忽略了多余的斜杠，因此它將獲取URL從而繞過嘗試的驗證，并導致SSRF漏洞。”

根據Claroty的說法，URL混淆也是繞過Log4Shell補丁的原因，因為在JNDI查找過程中使用了兩種不同的URL解析器：一個解析器用于驗證URL，另一個解析器用于獲取URL。

研究人員解釋說：“根據每個解析器處理URL的片段部分(#)的不同，權限也會發生變化。”“為了驗證URL的主機是否被允許，Java的URI被使用，它解析URL、提取主機，并檢查主機是否在允許主機的白名單中。事實上，如果我們使用Java的URI解析這個URL，我們會發現URL的主機號是127.0.0.1，它包含在白名單中。但是，在某些操作系統(主要是macOS)和特定配置上，當JNDI查找進程獲取此URL時，它不會嘗試從127.0.0.1獲取它，而是向127.0.0.1#.evilhost.com發出請求。這意味著雖然此惡意負載將繞過AllowedDaPost localhost驗證(由URI解析器完成)，但它仍將嘗試從遠程位置獲取類。”

URL解析安全漏洞

在他們的分析中，研究人員在第三方Web應用程序中發現了八個由URL解析混淆導致的高危漏洞。他們說，除了在不受支持的Flask版本中發現的那些之外，所有這些都已被修補，因此開發人員應該使用更新的版本更新他們的應用程序：

1. Flask-security開放重定向(Python，CVE-2021-23385)

2. Flask-security-too開放重定向(Python，CVE-2021-32618)

3. Flask-User開放重定向(Python，CVE-2021-23401)

4. Flask-unchained開放重定向(Python，CVE-2021-23393)

5. Belledonne的SIP堆棧空指針間接引用(DoS)(C，CVE-2021-33056)

6. Video.js跨站腳本(XSS)(JavaScript，CVE-2021-23414)

7. Nagios XI開放重定向(PHP，CVE-2021-37352)

8. Clearance開放重定向(Ruby，CVE-2021-23435)

開放重定向漏洞很容易被利用，因為它們可以進行欺騙、網絡釣魚和中間人攻擊(MITM)。當Web應用程序接受用戶控制的輸入，該輸入指定用戶在特定操作后將被重定向到的URL時，就會發生這種情況。例如，當用戶登錄網站時，他們可能會被重定向到惡意網站。

研究人員解釋說，開放式重定向攻擊通常通過驗證來阻止：“Web服務器驗證給定的URL，并且只允許屬于同一站點或受信任域列表的URL。”

URL庫混淆會干擾正確的驗證，就像Clearance漏洞一樣。研究人員指出，Clearance(Ruby的Rails框架中一個廣泛應用的第三方插件，可以實現簡單安全的電子郵件和密碼身份驗證)中的易受攻擊的函數是“return_to”。此函數在登錄/注銷過程之后調用，并且應該將用戶安全地重定向到他們之前請求的頁面。但是，如果可以說服目標單擊具有以下語法的URL，則可將其破壞：http://www.victim.com/////evil.com。

研究人員解釋說：“由于Rails忽略了URL中的多個斜杠，因此路徑段將完整到達Clearance(/////evil.com)并在其進行解析。”“由于URI.parse刪除了兩個斜杠，因此生成的URL是///evil.com。每當服務器將用戶重定向到此URL///evil.com時，瀏覽器都會將此網絡路徑相對引用轉換為指向evil.com域(主機)的絕對http://evil.com URL。”

Belledonne VoIP崩潰

在Belledonne的Linphone中發現了一個更有趣的漏洞，這是一個免費的IP語音軟電話、SIP客戶端和用于音頻和視頻通話的服務。根據分析，由于它處理SIP消息解析的方式，它遭受了scheme混淆。

研究人員解釋說：“通過研究Belledone的URL解析功能，我們發現[a]段代碼解析了to/from SIP header中的SIP URL。”“Belledone將SIP URL解析為通用URL，并使用strcasecmp檢查方案是SIP還是SIP，以及給定的URL是否為SIP URL。”

然而，他們解釋說，Belledonne generic_uri接受由不同URL組件創建的URL，而不需要存在特定組件。

他們總結說：“這意味著僅包含路徑而沒有URL scheme的URL是有效的URL。”“通過此方法，我們提供了一個只包含一個斜杠(/)的URL，導致URL的方案結果為NULL。然后，當Belledone使用strcasecmp時，它會比較一個NULL指針(因為沒有提供scheme)，從而導致NULL指針取消引用和應用程序崩潰。”

該團隊創建了一個概念驗證漏洞利用代碼，該代碼能夠通過簡單的惡意VoIP呼叫來使任何遠程用戶的應用程序崩潰，“要求受攻擊用戶的零交互”。

Team82和Synk研究人員指出，“可能會出現許多漏洞，從可能導致遠程代碼執行的SSRF漏洞到可能導致復雜網絡釣魚攻擊的開放重定向漏洞。”他們說，為了保護他們的應用程序，開發人員應采用以下措施：

使用盡可能少的解析器。研究人員說：“我們建議您完全避免使用URL解析器，而且一般情況下這是很容易實現。”

在microservice環境中傳輸解析的URL。他們指出：“如果microservice是在不同的框架或編程語言中實現，他們可能會使用不同的URL解析器。”“為了避免這個問題，你可以簡單地在前端microservice中解析URL，并以解析后的形式進一步傳輸它。”

了解與應用程序業務邏輯相關的解析器的差異。有時無法避免使用多個解析器，因此開發人員需要注意解析行為的差異。

在解析之前始終規范化URL。始終確保應用程序刪除多個正向/反向斜杠、空格和控制字符，以便在解析之前將URL恢復為正確的形式。

本文翻譯自：https://threatpost.com/url-parsing-bugs-dos-rce-spoofing/177493/如若轉載，請注明原文地址。