https url中的用户名和密码 [英] Username and password in https url

问题描述

考虑网址:https://foo:[e-mail]

上例中的用户名/密码部分是否符合 这个问题?

Does the username/password portion in the above example qualify as a "URL parameter", as defined in this question?

推荐答案

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

When you put the username and password in front of the host, this data is not sent that way to the server. It is instead transformed to a request header depending on the authentication schema used. Most of the time this is going to be Basic Auth which I describe below. A similar (but significantly less often used) authentication scheme is Digest Auth which nowadays provides comparable security features.

使用基本身份验证，来自问题的 HTTP 请求将如下所示:

With Basic Auth, the HTTP request from the question will look something like this:

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

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

The hash like string you see there is created by the browser like this: base64_encode(username + ":" + password).

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

To outsiders of the HTTPS transfer, this information is hidden (as everything else on the HTTP level). You should take care of logging on the client and all intermediate servers though. The username will normally be shown in server logs, but the password won't. This is not guaranteed though. When you call that URL on the client with e.g. curl, the username and password will be clearly visible on the process list and might turn up in the bash history file.

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

When you send passwords in a GET request as e.g. http://example.com/login.php?username=me&password=secure the username and password will always turn up in server logs of your webserver, application server, caches, ... unless you specifically configure your servers to not log it. This only applies to servers being able to read the unencrypted http data, like your application server or any middleboxes such as loadbalancers, CDNs, proxies, etc. though.

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

Basic auth is standardized and implemented by browsers by showing this little username/password popup you might have seen already. When you put the username/password into an HTML form sent via GET or POST, you have to implement all the login/logout logic yourself (which might be an advantage and allows you to more control over the login/logout flow for the added "cost" of having to implement this securely again). But you should never transfer usernames and passwords by GET parameters. If you have to, use POST instead. The prevents the logging of this data by default.

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

When implementing an authentication mechanism with a user/password entry form and a subsequent cookie-based session as it is commonly used today, you have to make sure that the password is either transported with POST requests or one of the standardized authentication schemes above only.

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

Concluding I could say, that transfering data that way over HTTPS is likely safe, as long as you take care that the password does not turn up in unexpected places. But that advice applies to every transfer of any password in any way.

这篇关于https url中的用户名和密码的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！