当前位置：文江博客话题详情

https url 中的用户名和密码

发布于 2024-10-17 06:55:08 字数 381 浏览 3 评论 0原文

考虑一下网址： https://foo:[电子邮件受保护]< /span>

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

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

亽野灬性zι浪 2024-10-24 06:55:08

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

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

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

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

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

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

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

当使用当前常用的用户/密码输入表单和基于 cookie 的会话来实现身份验证机制时，您必须确保密码是通过 POST 请求传输的，或者仅是上述标准化身份验证方案之一。

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

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.

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

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

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

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.

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.

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.

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.

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.

回复收藏 0 原文

~没有更多了~