Question

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

用户通过在浏览器中输入https://myserver.com
显示包含两个表单字段的用于unsername和password的登录对话框。
输入username和password并按login-button
使用GET向网址发送ajax请求：https://myusername:myPassword@myserver.com/foo/bar/metadata

根据我的理解，使用GET发送敏感数据绝不是一个好主意。但是HTTPS is the url string secure的答案说明了以下内容

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.

在同一个帖子中的另一个答案：

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仍可能存在安全问题：

the URL is stored in the logs on the server并且在同一个帖子中
leakage through browser history

这类似于？

    https://myusername:myPassword@myserver.com/foo/bar/metadata
    // or 
    https://myserver.com/?user=myUsername&pass=MyPasswort

关于此主题的其他问题：

在security.stackexchange上有其他信息：

但在我看来，有些方面仍未得到解答

问题

在我看来，上述观点是对不使用get的有效反对意见。是这样的;使用get来发送密码是一个坏主意吗？

这些攻击选项是否还有更多？

浏览器历史记录
服务器日志（假设网址存储在未加密或加密的日志中）
引用者信息（如果确实如此）

使用get？

由于

Answer 1

通过GET发送任何类型的敏感数据都是危险的，即使它是HTTPS。这些数据可能最终出现在服务器的日志文件中，并将包含在Referer标题中，链接到或包含在其他方面。它们也将保存在浏览器的历史记录中，因此攻击者可能会尝试通过对历史的攻击来猜测和验证链接的原始内容。

除此之外，您最好在security.stackexchange.com上提出这类问题。

Answer 2

这两种方法根本不同：

https://myusername:myPassword@myserver.com/foo/bar/metadata
https://myserver.com/?user=myUsername&pass=MyPasswort

myusername:myPassword@是"User Information"（此表单在最新的URI RFC中实际上已弃用），而?user=myUsername&pass=MyPasswort是查询的一部分。

如果你从RFC 3986看这个例子：

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

myusername:myPassword@是权限的一部分。在实践中，通常使用HTTP（基本）身份验证标头来传达此信息。在服务器端，通常不会记录标题（如果是，则客户端是否将它们输入到其位置栏或通过输入对话框将没有任何区别）。通常（虽然它依赖于实现），浏览器不会将其存储在位置栏中，或者至少它们会删除密码。似乎Firefox将userinfo保留在浏览器历史记录中，而Chrome不保留（和IE doesn't really support them without workaround）

相比之下，?user=myUsername&pass=MyPasswort是查询，它是URI中不可或缺的一部分，它是作为HTTP Request-URI发送的。这将在浏览器的历史记录和服务器的日志中。这也将在推荐人中传递。

简而言之，myusername:myPassword@显然旨在传达可能敏感的信息，而浏览器通常旨在适当地处理此问题，而浏览器无法猜测哪些部分的查询是敏感的，不是：期望信息泄漏。

引用者信息通常也不会泄露给第三方，因为来自HTTPS页面的Referer标头通常仅与HTTPS上的其他请求一起发送到同一主机。（当然，如果您使用过https://myserver.com/?user=myUsername&pass=MyPasswort，那么这将在同一主机的日志中，但由于它保留在相同的服务器日志中，因此您没有太多价值。）

这在HTTP specification (Section 15.1.3)：

中指定

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

虽然它只是一个＆＃34;不应该＆＃34;，但是Internet Explorer，Chrome和Firefox似乎都是这样实现的。这是否适用于从一个主机到另一个主机的HTTPS请求取决于浏览器及其版本。

现在可以使用<meta>标头覆盖此行为，如this question和this draft specification中所述，但您不会在敏感页面上执行此操作无论如何都使用?user=myUsername&pass=MyPasswort。

请注意，HTTP specification (Section 15.1.3)的其余部分也相关：

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

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

Answer 3

假设用户点击了一个按钮并跟随客户端浏览器生成的请求。

https://www.site.com/?username=alice&password=b0b123！

<强> HTTPS

首先是第一件事。 HTTPS与此主题无关。因为从攻击者的角度来看，使用POST或GET并不重要。当流量是HTTP时，攻击者可以轻松地从查询字符串或直接POST请求主体中获取敏感数据。因此它没有任何区别。

服务器日志

我们知道Apache，Nginx或其他服务将每个HTTP请求记录到日志文件中。这意味着查询字符串（？username = alice＆amp; password = b0b123！）将写入日志文件。这可能很危险，因为您的系统管理员也可以访问此数据并获取所有用户凭据。当您的应用程序服务器泄露时，也可能发生另一种情况我相信你将密码存储为哈希。如果您使用强大的散列算法（如SHA256），您的客户端密码将更安全地抵御黑客。但是黑客可以直接访问日志文件，将密码作为带有非常基本shell脚本的纯文本获取。

推荐人信息

我们假设客户在上面的链接上打开了。当客户端浏览器获取html内容并尝试解析它时，它将看到图像标记。此图像可以在您的域外托管（postimage或类似服务，或直接在黑客控制下的域）。浏览器发出HTTP请求以获取图像。但是目前的网址是https://www.site.com/?username=alice&password=b0b123！这将成为参考信息！

这意味着alice和她的密码将被传递到另一个域，并且可以直接从Web日志访问。这是非常重要的安全问题。

此主题让我想起会话修复漏洞。请阅读以下OWASP文章，了解与会话几乎相同的安全漏洞。（https://www.owasp.org/index.php/Session_fixation）值得一读。

Answer 4

社区对这些问题提出了一个广泛的看法，上述立场就这个问题而言。但是，GET请求通常可能需要身份验证。如上所述，将用户名/密码作为URL的一部分发送永远不会正确，但这通常不是通常处理认证信息的方式。当向服务器发送资源请求时，服务器通常在响应中响应401和Authentication头，客户端使用身份验证信息（在Basic方案中）发送Authorization头。现在，来自客户端的第二个请求可以是POST或GET请求，没有什么可以阻止它。因此，一般来说，它不是请求类型，而是传达信息的模式是有问题的。

参考http://en.wikipedia.org/wiki/Basic_access_authentication

Answer 5

考虑一下：

https://www.example.com/login

登录页面中的Javascript：

$.getJSON("/login?user=joeblow&pass=securepassword123");

引荐来源现在是什么？

如果您担心安全性，则可能需要额外一层：

var a = Base64.encode(user.':'.pass);
$.getJSON("/login?a="+a);

尽管未加密，但至少看不到数据。

安全问题是否使用基于https的GET请求发送密码有效？

问题

5 个答案: