日前，有研究人員對 16 個不同的統(tǒng)一資源定位符（ URL ）解析庫進行調(diào)研后，發(fā)現(xiàn)了不一致和混亂的情形，它們可以被不法分子用來繞過驗證機制，為眾多攻擊途徑敞開大門。隨后，兩家網(wǎng)絡(luò)安全公司 Claroty 和 Synk 聯(lián)合開展了深入的分析工作，結(jié)果發(fā)現(xiàn)，用C 、JavaScript 、 PHP 、 Python 和 Ruby 等語言編寫的許多第三方庫存在 8 個安全漏洞，多個 Web 應(yīng)用程序使用這些第三方庫。
發(fā)現(xiàn)的8個漏洞包括Belledonne’s SIP Stack（C，CVE-2021-33056）、Video.js（JavaScript，CVE-2021-23414）、Nagios XI（PHP，CVE-2021-37352）、Flask-security（Python，CVE-2021-23385）、Flask-security-too（Python，CVE-2021-32618）、Flask-unchained（Python，CVE-2021-23393）、Flask-User（Python，CVE-2021-23401）、Clearance（Ruby，CVE-2021-23435），所有這些漏洞此后已由各自的維護人員修復。
研究人員表示：“ URL 解析中的混亂可能導致軟件（比如 Web 應(yīng)用程序）出現(xiàn)異常行為，可能被威脅分子用來引發(fā)拒絕服務(wù)攻擊、泄露信息，或可能實施遠程代碼執(zhí)行攻擊。”由于 URL 是一種用來請求和檢索位于本地或 Web 上資源的基本機制，解析庫如何解釋 URL 請求方面的差異可能會給用戶帶來重大風險。一個典型例子是 2021 年 12 月在 Log4j 日志框架中暴露的 Log4Shell 嚴重漏洞。該漏洞源于攻擊者控制的惡意字符串被評估、并由易受攻擊的應(yīng)用程序記錄時，導致 JNDI 查詢連接到攻擊者運行的服務(wù)器，從而執(zhí)行任意 Java 代碼。雖然 Apache 軟件基金會（ ASF ）迅速發(fā)布了補丁以修復漏洞，但人們很快發(fā)現(xiàn)，輸入精心設(shè)計的內(nèi)容（格式為“ $”），可以繞過緩解措施，再次允許遠程 JNDI 查詢執(zhí)行代碼。
研究人員表示：“這種繞過源于在 JNDI 查詢過程中使用了兩個不同的 URL 解析器，一個解析器用于驗證 URL ，另一個用于獲取 URL ；URL 的 Authority 部分也發(fā)生變化，這取決于每個解析器如何處理 URL 的 Fragment 部分（#）。” 具體來說，如果輸入作為常規(guī)的 HTTP URL 來處理， Authority 部分（域名和端口號的組合）一遇到 fragment 標識符就結(jié)束；而作為 LDAP URL 來處理時，解析器會分配整個“127.0.0[.]1#.evilhost.com:1389”作為 Authority ，因為 LDP URL 規(guī)范不考慮該 fragment 。
的確，使用多個解析器是這8個漏洞出現(xiàn)的主要原因之一，還有一個原因是，庫遵循不同的 URL 規(guī)范時存在不一致，從而導致了問題，這實際上帶來了可利用的漏洞。不一致的情形多種多樣，如 URL 含有反斜杠（“\”）、不規(guī)則數(shù)量的斜杠（比如https:///www.example[.]com）或 URL 編碼數(shù)據(jù)（“%”）， 以及 URL 缺少 URL 方案等，這后一種情形可被用來實施遠程代碼執(zhí)行攻擊，甚至發(fā)動拒絕服務(wù)（ DoS ）和開放重定向網(wǎng)絡(luò)釣魚攻擊。研究人員表示：“許多實際的攻擊場景可能來自不同的解析原語。”為了保護應(yīng)用程序免受 URL 解析漏洞的影響，“有必要充分了解整個過程中牽涉哪些解析器，以及解析器之間的差異，了解它們?nèi)绾谓忉尣煌袷?、有誤的 URL 以及它們支持哪些類型的 URL 。”
