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

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

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

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

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

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

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

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

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

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

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

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

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

From a "sniff the network packet" point of view a GET request is safe, as the browser will first establish the secure connection and then send the request containing the GET parameters. But GET url's will be stored in the users browser history / autocomplete, which is not a good place to store e.g. password data in. Of course this only applies if you take the broader "Webservice" definition that might access the service from a browser, if you access it only from your custom application this should not be a problem.

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

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

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

我不同意关于……的说法。Slough响应中的HTTP引用泄漏(目标页面中的外部图像可能泄漏密码)。

HTTP 1.1 RFC明确声明:

客户不应包括推荐人 (非安全)HTTP中的报头字段 请求参考页是否为 通过安全协议传输。

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