security - https url中的用户名和密码

Question

考虑 URL： https://foo:password@example.com

上述示例中的用户名/密码部分是否符合此问题中定义的“URL 参数” ？

Answer 1

当您将用户名和密码放在主机前面时，此数据不会以这种方式发送到服务器。它会根据所使用的身份验证模式转换为请求标头。大多数情况下，这将是我在下面描述的基本身份验证。一个类似（但很少使用）的身份验证方案是Digest Auth，它现在提供了类似的安全功能。

使用 Basic Auth，来自问题的 HTTP 请求将如下所示：

GET / HTTP/1.1
Host: example.com
Authorization: Basic Zm9vOnBhc3N3b3Jk

您在那里看到的类似哈希的字符串是由浏览器创建的，如下所示base64_encode(username + ":" + password)：

对于 HTTPS 传输的外部人员，此信息是隐藏的（与 HTTP 级别上的所有其他内容一样）。不过，您应该注意登录客户端和所有中间服务器。用户名通常会显示在服务器日志中，但密码不会。但是，这并不能保证。当您在客户端上使用 eg 调用该 URL 时curl，用户名和密码将在进程列表中清晰可见，并且可能会出现在 bash 历史文件中。

当您在 GET 请求中发送密码时，例如http://example.com/login.php?username=me&password=secure用户名和密码将始终出现在您的网络服务器、应用程序服务器、缓存等的服务器日志中...除非您专门将服务器配置为不记录它。这仅适用于能够读取未加密 http 数据的服务器，例如您的应用程序服务器或任何中间件，例如负载均衡器、CDN、代理等。

基本身份验证由浏览器标准化并通过显示您可能已经看到的这个小用户名/密码弹出窗口来实现。当您将用户名/密码放入通过 GET 或 POST 发送的 HTML 表单中时，您必须自己实现所有登录/注销逻辑（这可能是一个优势，并允许您更好地控制添加的登录/注销流程“成本”必须再次安全地实施）。但是你不应该通过GET 参数传输用户名和密码。如果必须，请改用 POST。默认情况下会阻止记录此数据。

在使用用户/密码输入表单和随后的基于 cookie 的会话（如今天常用的那样）实现身份验证机制时，您必须确保密码是通过 POST 请求传输或仅使用上述标准化身份验证方案之一传输的。

最后我可以说，通过 HTTPS 以这种方式传输数据可能是安全的，只要您注意密码不会出现在意外的地方。但该建议适用于以任何方式传输任何密码。