HTTPS查询字符串安全吗？

我正在创建一个使用HTTPS的基于Web的安全API；但是，如果我允许用​​户使用查询字符串来配置它（包括发送密码），这也将是安全的吗？还是我应该通过POST强制进行设置？

是的。但是使用GET处理敏感数据是一个坏主意，原因有以下几个：

• 主要是HTTP引荐来源网址泄漏（目标页面中的外部图像可能会泄漏密码[1]）
• 密码将存储在服务器日志中（这显然是错误的）
• 浏览器中的历史记录缓存

因此，即使Querystring是安全的，也不建议通过querystring传输敏感数据。

[1]尽管我需要指出RFC指出浏览器不应将引荐来源网址从HTTPS发送到HTTP。但这并不意味着坏的第三方浏览器工具栏或HTTPS站点的外部图像/闪存都不会泄漏它。

从“嗅探网络数据包”的角度来看，GET请求是安全的，因为浏览器将首先建立安全连接，然后发送包含GET参数的请求。但是GET网址将存储在用户的浏览器历史记录/自动填充中，这不是存储密码数据的好地方。当然，仅当您采用可能从浏览器访问该服务的更广泛的“ Webservice”定义时，该方法才适用，如果仅从自定义应用程序访问它，则应该不会有问题。

因此，至少应将post用于密码对话框。另外，正如在littlegeek发布的链接中指出的那样，更可能将GET URL写入服务器日志。

是的，您的查询字符串将被加密。

其背后的原因是查询字符串是HTTP协议的一部分，而HTTP协议是应用程序层协议，而安全性（SSL / TLS）部分来自传输层。首先建立SSL连接，然后将查询参数（属于HTTP协议）发送到服务器。

建立SSL连接时，您的客户端将按顺序执行以下步骤。假设您正尝试登录名为example.com的站点，并希望使用查询参数发送凭据。您的完整URL可能如下所示：

https://example.com/login?username=alice&password=12345)

1. 您的客户端（例如，浏览器/移动应用程序）将首先使用DNS请求将您的域名解析example.com为IP地址(124.21.12.31)。当查询该信息时，仅使用特定于域的信息，即仅example.com将使用。
2. 现在，您的客户端将尝试使用IP地址连接到服务器，124.21.12.31并尝试连接到端口443（SSL服务端口，而不是默认的HTTP端口80）。
3. 现在，位于的服务器example.com将其证书发送给您的客户端。
4. 您的客户端将验证证书，并开始为您的会话交换共享密钥。
5. 成功建立安全连接后，才可以通过安全连接发送查询参数。

因此，您不会公开敏感数据。但是，使用此方法通过HTTPS会话发送凭据不是最佳方法。您应该采用其他方法。

是。HTTPS会话的整个文本由SSL保护。这包括查询和标题。在这方面，POST和GET完全相同。

至于您的方法的安全性，没有经过适当检查就没有真正的说法。

SSL首先连接到主机，因此主机名和端口号以明文形式传输。当主机响应并且质询成功时，客户端将使用实际URL（即第三个斜杠之后的内容）对HTTP请求进行加密，然后将其发送到服务器。

有几种方法可以打破这种安全性。

可以将代理配置为充当“中间人”。基本上，浏览器将连接到真实服务器的请求发送到代理。如果以这种方式配置代理，它将通过SSL连接到真实服务器，但浏览器仍会与代理对话。因此，如果攻击者可以访问代理，则他可以以明文形式查看流经代理的所有数据。

您的请求也将在浏览器历史记录中显示。用户可能会倾向于将站点添加为书签。一些用户安装了书签同步工具，因此密码可能会出现在deli.ci.us或其他地方。

最后，可能有人入侵了您的计算机，并安装了键盘记录器或屏幕抓取工具（许多Trojan Horse型病毒也感染了）。由于密码可以直接在屏幕上看到（而不是密码对话框中的“ *”），因此这是另一个安全漏洞。

结论：关于安全性，请始终遵循常规。有太多您不知道，不会想到的东西，它们会折断您的脖子。

是的，只要没有人看着您的显示器。

我不同意有关说法[...] HTTP引用泄漏（在目标页面的外部图像可能会泄露密码）在斯劳的回应。

HTTP 1.1 RFC 明确指出：

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

无论如何，服务器日志和浏览器历史记录是不将敏感数据放入查询字符串中的充分原因。

是的，从建立HTTPS连接的那一刻起，一切都是安全的。POST时的查询字符串（GET）通过SSL发送。

您可以添加一些盐作为MD5哈希参数发送密码。在服务器端比较它的身份验证。