dede模板建站HTTP重定向上通过DNS的部分密码泄漏libcurl

可以诱骗libcurl在解析主机名之前在主机名之前添加一部分密码，这可能会导致部分密码通过网络和DNS服务器泄漏。

请求HTTP资源时，可以为libcurl提供用于HTTP认证的用户名和密码-用于HTTP认证，例如Basic，Digest，NTLM等。凭证可以CURLOPT_USERPWD与CURLOPT_USERNAME和一起设置，也可以与分开设置CURLOPT_PASSWORD。重要细节：这些字符串以纯C字符串的形式提供给libcurl，并且不应被URL编码。

此外，libcurl还允许使用标准RFC 3986格式在URL中设置凭据http://user:[email protected]/path。在这种情况下，名称和密码是URL编码的，因为它们就是在URL中出现的方式。

如果设置了选项，则它们将覆盖URL中设置的凭据。

在内部，这是通过将凭据存储在“ URL对象”中来进行处理的，以便仅存储与该单个URL关联的一组凭据。

当libcurl处理HTTP传输的相对重定向（而不是***URL重定向）时，服务器仅向客户端发送新路径，并且该路径将应用于现有URL。在libcurl上“应用”相对路径是通过libcurl首先从其拥有的所有组件中生成一个完整的***URL，然后应用重定向，***后将URL再次解构为单独的组件。

此安全漏洞源于一个事实，即使用上述curl_easy_setopt选项之一进行设置时，curl无法正确地对凭据数据进行URL编码。这会使curl在进行重定向时会生成格式错误的完整URL，并且***终对URL的重新解析将变得很糟糕，并错误地认为密码字段的一部分属于主机名。

然后，错误的主机名将用于名称解析查找中，从而可能通过网络（如果使用了纯DNS）以明文形式泄漏主机名+部分密码（尤其是使用的DNS服务器）。

如果@在密码字段中使用at符号（），则会触发密码泄漏，如下所示：[email protected]。如果我们还考虑一个用户dan，curl将生成一个完整的URL，例如：

https://dan:[email protected]@example.com/path

...正确的选择应该是：

https://dan:[email protected]/path

...解析错误生成的URL时，libcurl***终将以与主机对话的用户名dan和密码结束。然后，该错误的主机名将传递给使用中的名称解析器函数（对于所有典型情况，返回“无法解析主机名”错误）。[email protected]

名称解析中没有暗示实际上是主机名之前使用的密码有多大部分（即，观察者不会知道的左侧有多少数据@），但是当然可以足以让攻击者弄清楚其余的线索。

我们尚不知道对此漏洞有任何利用。

信息

触发此缺陷的要求。

密码设置与@在它HTTP传输curl遵循的相对重定向（CURLOPT_FOLLOWLOCATION启用）

这个错误是在commit46e164069d中引入的，***初是在curl7.62.0中发行的。

curl工具的用户以及使用libcurl的应用程序都可能发生此缺陷。

已报告此错误，无意中已将其修复，并在任何人意识到其安全影响之前将其推送到公共源存储库。

如果使用HTTP-over-HTTPS，则此缺陷的影响会有所降低，因为从那时起，该名称至少在网络上不会由被动的旁观者观察到，而只能由DoH服务器观察到。

常见漏洞和披露（CVE）项目为此问题分配了名称CVE-2020-8169。

CWE-200：向未经授权的演员公开敏感信息

严重程度：5.5（中）

受影响的版本

受影响的版本：libcurl7.62.0到7.70.0（含）不受影响的版本：libcurl <7.62.0

libcurl被许多应用程序使用，但并不总是这样宣传。

解决方案

一个为CVE-2020-8169的修复

推荐建议

我们建议您按照优先顺序立即执行以下操作之一：

A-将curl升级到7.71.0版

B-在您的libcurl版本上应用补丁并重建

C-禁用CURLOPT_FOLLOWLOCATION或重定向到HTTP（S）