使用 GET 请求通过 https 发送密码的安全问题是否有效? [英] Are security concerns sending a password using a GET request over https valid?

问题描述

我们的网页使用了 sapui5-构建 spa 的框架.浏览器和服务器之间的通信使用 https.登录页面的交互如下:

We have webpage which uses the sapui5-framework to build a spa. The communication between the browser and the server uses https. The interaction to log into the page is the following:

1. 用户通过在浏览器中输入 https://myserver.com 来打开网站
2. 显示一个登录对话框，其中包含两个用于 unsername 和密码的表单字段.
3. 输入用户名和密码并按下登录按钮
后
4. 使用 GET 向 URL 发送 ajax 请求:https://myusername:[e-mail]/foo/bar/metadata

1. The user opens the website by entering https://myserver.com in the browser
2. A login dialogue with two form fields for unsername and password is shown.
3. After entering username and password and pressing the login-button
4. an ajax-request is send using GET to the URL: https://myusername:[e-mail]/foo/bar/metadata

根据我的理解，使用 GET 发送敏感数据从来都不是一个好主意.但是这个对 HTTPS is the url string secure 的回答说明了以下内容

According to my understanding using GET to send sensitive data is never a good idea. But this answer to HTTPS is the url string secure says the following

HTTPS Establishes an underlying SSL conenction before any HTTP data is
transferred. This ensures that all URL data (with the exception of
hostname, which is used to establish the connection) is carried solely
within this encrypted connection and is protected from
man-in-the-middle attacks in the same way that any HTTPS data is.

在同一线程中的另一个答案中:

An in another answer in the same thread:

These fields [for example form field, query strings] are stripped off
of the URL when creating the routing information in the https packaging 
process by the browser and are included in the encrypted data block.

The page data (form, text, and query string) are passed in the
encrypted block after the encryption methods are determined and the
handshake completes.

但使用 get 似乎仍然存在安全问题:

• URL 存储在服务器上的日志中 和同一线程中
• 浏览器历史记录泄露

• the URL is stored in the logs on the server and in the same thread
• leakage through browser history

URL 是否属于这种情况?

Is this the case for URLs like?

    https://myusername:[e-mail]/foo/bar/metadata
    // or 
    https://myserver.com/?user=myUsername&pass=MyPasswort

关于此主题的其他问题:

Additional questions on this topic:

• 通过 ssl 传递 get 变量是否安全
• 是否考虑了 通过 https 在 json 中发送密码安全
• 如何通过 GET/POST 安全发送密码?

关于 security.stackexchange 是附加信息:

On security.stackexchange are additional informations:

• 使用ssl时可以嗅探url莉>
• ssl 与 get 和 post

但在我看来还有几个方面没有回答

But in my opinion a few aspects are still not answered

在我看来，上述几点是不使用 get 的有效反对意见.是这样吗?使用 get 发送密码是个坏主意吗?

In my opinion the mentioned points are valid objections to not use get. Is the case; is using get for sending passwords a bad idea?

这些是攻击选项吗?还有更多吗?

Are these the attack options, are there more?

• 浏览器历史记录
• 服务器日志(假设 url 存储在未加密或加密的日志中)
• 推荐人信息(如果确实如此)

使用 get 通过 https 发送敏感数据(密码)时存在哪些攻击选项?

Which attack options do exist when sending sensitive data (password) over https using get?

谢谢

推荐答案

这两种方法根本不同:

• https://myusername:[e-mail]/foo/bar/metadata
• https://myserver.com/?user=myUsername&pass=MyPasswort

myusername:myPassword@ 是 用户信息"(在最新的 URI RFC 中实际上已弃用此表单)，而 ?user=myUsername&pass=MyPasswort 是查询的一部分.

myusername:myPassword@ is the "User Information" (this form is actually deprecated in the latest URI RFC), whereas ?user=myUsername&pass=MyPasswort is part of the query.

如果您从 RFC 3986 中查看此示例:

If you look at this example from RFC 3986:

     foo://example.com:8042/over/there?name=ferret#nose
     \_/   \______________/\_________/ \_________/ \__/
      |           |            |            |        |
   scheme     authority       path        query   fragment
      |   _____________________|__
     /  /                        
     urn:example:animal:ferret:nose

myusername:myPassword@ 是权限的一部分.在实践中，使用 HTTP (Basic) 身份验证标头通常会用于传达此信息.在服务器端，标题通常不会被记录(如果有的话，客户端是否将它们输入到他们的位置栏或通过输入对话框将没有区别).通常(尽管它依赖于实现)，浏览器不会将它存储在地址栏中，或者至少它们会删除密码.Firefox 似乎将用户信息保留在浏览器历史记录中，而 Chrome 没有(并且 IE 在没有解决方法的情况下并不真正支持它们)

myusername:myPassword@ is part of the authority. In practice, use HTTP (Basic) authentication headers will generally be used to convey this information. On the server side, headers are generally not logged (and if they are, whether the client entered them into their location bar or via an input dialog would make no difference). In general (although it's implementation dependent), browsers don't store it in the location bar, or at least they remove the password. It appears that Firefox keeps the userinfo in the browser history, while Chrome doesn't (and IE doesn't really support them without workaround)

相比之下，?user=myUsername&pass=MyPasswort 是 query，是 URI 的一个更完整的部分，它作为 HTTP 请求 URI.这将在浏览器的历史记录和服务器的日志中.这也将在引用中传递.

In contrast, ?user=myUsername&pass=MyPasswort is the query, a much more integral part of the URI, and it is send as the HTTP Request-URI. This will be in the browser's history and the server's logs. This will also be passed in the referrer.

简单来说，myusername:myPassword@ 显然旨在传达潜在敏感的信息，而浏览器通常设计为适当地处理这一点，而浏览器无法猜测其中的哪一部分查询是敏感的，哪些不是:预计信息会泄漏.

To put it simply, myusername:myPassword@ is clearly designed to convey information that is potentially sensitive, and browsers are generally designed to handle this appropriately, whereas browsers can't guess which part of which queries are sensitive and which are not: expect information leakage there.

引用信息通常也不会泄露给第三方，因为来自 HTTPS 页面的 Referer 标头通常仅与 HTTPS 上的其他请求一起发送到同一主机.(当然，如果您使用了 https://myserver.com/?user=myUsername&pass=MyPasswort，这将在同一主机的日志中，但您并没有成功非常值得，因为它保留在相同的服务器日志中.)

The referrer information will also generally not leak to third parties, since the Referer header coming from an HTTPS page is normally only sent with other request on HTTPS to the same host. (Of course, if you have used https://myserver.com/?user=myUsername&pass=MyPasswort, this will be in the logs of that same host, but you're not making it much worth since it stays on the same server logs.)

这在 HTTP 规范(第 15.1 节.3):

如果引用页面是使用安全协议传输的，则客户端不应在(非安全)HTTP 请求中包含 Referer 标头字段.

Clients SHOULD NOT include a Referer header field in a (non-secure) HTTP request if the referring page was transferred with a secure protocol.

尽管它只是不应该"，但 Internet Explorer、Chrome 和 Firefox 似乎是通过这种方式实现的.这是否适用于从一台主机到另一台主机的 HTTPS 请求取决于浏览器及其版本.

Although it is just a "SHOULD NOT", Internet Explorer, Chrome and Firefox seem to implement it this way. Whether this applies to HTTPS requests from one host to another depends on the browser and its version.

现在可以覆盖此行为，如这个问题和本规范草案，使用 标头，但您不会无论如何，不​​要在使用 ?user=myUsername&pass=MyPasswort 的敏感页面上这样做.

It is now possible to override this behaviour, as described in this question and this draft specification, using a <meta> header, but you wouldn't do that on a sensitive page that uses ?user=myUsername&pass=MyPasswort anyway.

请注意 HTTP 规范的其余部分(第 15.1 节.3) 也是相关的:

Note that the rest of HTTP specification (Section 15.1.3) is also relevant:

使用 HTTP 协议的服务的作者不应该使用基于 GET 的表单来提交敏感数据，因为这会导致这些数据被编码到请求 URI 中.许多现有的服务器、代理和用户代理会在第三方可能看到的某个地方记录请求 URI.服务器可以使用基于 POST 的表单提交来代替

Authors of services which use the HTTP protocol SHOULD NOT use GET based forms for the submission of sensitive data, because this will cause this data to be encoded in the Request-URI. Many existing servers, proxies, and user agents will log the request URI in some place where it might be visible to third parties. Servers can use POST-based form submission instead

使用 ?user=myUsername&pass=MyPasswort 与使用基于 GET 的表单完全一样，虽然可以包含 Referer 问题，但有关日志和历史记录的问题仍然存在.

Using ?user=myUsername&pass=MyPasswort is exactly like using a GET based form and, while the Referer issue can be contained, the problems regarding logs and history remain.

这篇关于使用 GET 请求通过 https 发送密码的安全问题是否有效?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！