URL解析错误导致DoS、RCE等

研究人员警告说，由于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恢复为正确的形式。

本文翻