HTTPS查询字符串安全吗?

小开

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

至于你的方法的安全性，没有经过适当的检查，也很难说。

小开

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

小开

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

所以使用post至少密码对话框应该是首选的。另外，正如littlegeek在链接中指出的那样，GET URL更有可能写入你的服务器日志。

小开

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

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

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

您的请求也将在浏览器历史记录中可见。用户可能会忍不住收藏该网站。有些用户安装了书签同步工具，因此密码可能会出现在deli.ci.us或其他地方。

最后，有人可能已经侵入了你的电脑，并安装了键盘记录器或屏幕刮板(许多特洛伊木马类型的病毒都这样做)。由于密码直接显示在屏幕上(而不是密码对话框中的“*”)，这是另一个安全漏洞。

结论:当涉及到安全问题时，总是要依靠惯用的方法。有太多的事情是你不知道的，不会想到的，这会让你崩溃。

小开

最佳答案

是的，它是。但是对敏感数据使用GET是一个坏主意的几个原因:

主要是HTTP引用泄漏(目标页面中的外部图像可能泄漏密码[1])
密码将存储在服务器日志中(这显然很糟糕)
浏览器中的历史缓存

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

虽然我需要注意的是，RFC声明，浏览器不应该发送从HTTPS到HTTP的引用。但这并不意味着糟糕的第三方浏览器工具栏或HTTPS网站的外部图像/flash不会泄露它。

小开

我不同意绝望的反应中关于[…HTTP引用泄露(目标页面中的外部图像可能泄露密码)的说法。

HTTP 1.1 RFC 明确状态:

客户端不应该包含一个引用者 (非安全)HTTP中的报头字段请求参考页是否为

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

小开

是的，只要没人越过你的肩膀看显示器。

小开

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

小开

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

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

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

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

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

因此，您不会暴露敏感数据。但是，使用这种方法通过HTTPS会话发送凭据并不是最好的方法。你应该另辟蹊径。