可以诱骗libcurl在解析主机名之前在主机名之前添加一部分密码，这可能会导致部分密码通过网络和DNS服务器泄漏。
请求HTTP资源时，可以为libcurl提供用于HTTP认证的用户名和密码-用于HTTP认证，例如Basic，Digest，NTLM等。凭证可以CURLOPT_USERPWD与CURLOPT_USERNAME和 一起设置，也可以与分开设置 CURLOPT_PASSWORD。重要细节：这些字符串以纯C字符串的形式提供给libcurl，并且不应被URL编码。
此外，libcurl还允许使用标准RFC 3986格式在URL中设置凭据http://user:password@host/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符号（），则会触发密码泄漏，如下所示：passw@rd123。如果我们还考虑一个用户dan，curl将生成一个完整的URL，例如：
https://dan:passw@rd123@example.com/path
…正确的选择应该是：
https://dan:passw%40rd123@example.com/path
…解析错误生成的URL时，libcurl***终将以与主机对话的用户名dan和密码结束。然后，该错误的主机名将传递给使用中的名称解析器函数（对于所有典型情况，返回“无法解析主机名”错误）。passwrd123@example.com
名称解析中没有暗示实际上是主机名之前使用的密码有多大部分（即，观察者不会知道的左侧有多少数据@），但是当然可以足以让攻击者弄清楚其余的线索。
我们尚不知道对此漏洞有任何利用。
信息
触发此缺陷的要求。
- 密码设置与@在它
- HTTP传输
- curl遵循的相对重定向（CURLOPT_FOLLOWLOCATION启用）
这个错误是在commit 46e164069d中引入的，***初是在curl 7.62.0中发行的。
curl工具的用户以及使用libcurl的应用程序都可能发生此缺陷。
已报告此错误，无意中已将其修复，并在任何人意识到其安全影响之前将其推送到公共源存储库。
如果使用HTTP-over-HTTPS，则此缺陷的影响会有所降低，因为从那时起，该名称至少在网络上不会由被动的旁观者观察到，而只能由DoH服务器观察到。
常见漏洞和披露（CVE）项目为此问题分配了名称CVE-2020-8169。
CWE-200：向未经授权的演员公开敏感信息
严重程度：5.5（中）
受影响的版本
- 受影响的版本：libcurl 7.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）
感谢您阅读这篇dede模板建站HTTP重定向上通过DNS的部分密码泄漏libcurl文章，希望可以帮助您解决使用织梦cms途中的问题，更多相关织梦cms教程关注我们万条网吧。
请先 ！