我正在创建一个使用HTTPS的基于Web的安全API;但是，如果我允许用户使用查询字符串配置它（包括发送密码）这也是安全的，还是应该通过POST强制它？
答案 0 :(得分：409)
是的，确实如此。 但是，对于敏感数据使用GET是一个坏主意，原因如下：
因此，即使Querystring受到保护，也不建议通过查询字符串传输敏感数据。
[1]虽然我需要注意RFC规定浏览器不应该将引用从HTTPS发送到HTTP。但这并不意味着糟糕的第三方浏览器工具栏或来自HTTPS站点的外部图像/闪存不会泄漏它。
答案 1 :(得分：68)
从“嗅探网络数据包”的角度来看，GET请求是安全的，因为浏览器将首先建立安全连接，然后发送包含GET参数的请求。但GET网址将存储在用户浏览器历史记录/自动填充中，这不是存储的好地方，例如密码数据。当然，这仅适用于您从浏览器访问可能访问服务的更广泛的“Webservice”定义，如果您只从自定义应用程序访问它，这应该不是问题。
因此，首选使用post至少用于密码对话框。同样如链接中指出的那样，littlegeek发布的GET URL更有可能被写入您的服务器日志。
答案 2 :(得分：32)
是，您的查询字符串将被加密。
背后的原因是查询字符串是HTTP协议的一部分，它是一个应用层协议，而安全(SSL/TLS)部分来自传输层。首先建立SSL连接，然后发送到服务器的查询参数（属于http协议）。
建立SSL连接时，您的客户将按顺序调用以下步骤。假设您尝试登录名为 example.com 的站点，并希望使用查询参数发送您的凭据。您的完整URL可能如下所示。
(e.g https://example.com/login?username=alice&password=12345)
(example.com)请求将您的域名IP解析为(124.21.12.31)地址DNS。查询该信息时，仅使用特定于域的信息。即：仅使用example.com。IP地址124.21.12.31连接到服务器，并尝试连接到端口443（SSL服务端口，而不是默认http端口80）。example.com的服务器会将其证书发送给您的客户。因此，您不会暴露敏感数据。但是，使用此方法通过https会话发送凭据不是最佳方法。你应该采取不同的方法。
答案 3 :(得分：25)
是。 HTTPS会话的整个文本由SSL保护。这包括查询和标题。在这方面，POST和GET将完全相同。
关于你的方法的安全性，如果没有适当的检查，没有真正的方法可以说。
答案 4 :(得分：22)
SSL首先连接到主机，因此主机名和端口号将以明文形式传输。当主机响应并且挑战成功时，客户端将使用实际URL（即第三个斜杠之后的任何内容）加密HTTP请求，并将其发送到服务器。
有几种方法可以打破这种安全性。
可以将代理配置为充当“中间人”。基本上，浏览器将连接到真实服务器的请求发送到代理。如果以这种方式配置代理，它将通过SSL连接到真实服务器，但浏览器仍将与代理通信。因此，如果攻击者可以访问代理，他可以以明文形式查看流经它的所有数据。
您的请求也会显示在浏览器历史记录中。用户可能会想要为网站添加书签。有些用户安装了书签同步工具，因此密码最终可能会出现在deli.ci.us或其他地方。
最后，有人可能已经攻击了您的计算机并安装了键盘记录程序或屏幕抓取程序（以及许多特洛伊木马类型的病毒）。由于密码直接在屏幕上可见（而不是密码对话框中的“*”），这是另一个安全漏洞。
结论：在安全方面，总是依赖于人迹罕至的道路。有太多你不知道，不会想到，哪个会打破你的脖子。
答案 5 :(得分：9)
我不同意Slough's response中关于 [...] HTTP引用漏洞（目标页面中的外部图像可能泄漏密码）的声明。
HTTP 1.1 RFC explicitly states：
客户不应包含Referer （非安全）HTTP中的头字段 如果推荐页面是请求 使用安全协议进行转移。
无论如何，服务器日志和浏览器历史记录不足以让敏感数据放入查询字符串中。
答案 6 :(得分：9)
是的，只要没有人在监视器上看着你的肩膀。
答案 7 :(得分：8)
是的，从建立HTTPS连接的那一刻起，一切都是安全的。作为POST的查询字符串（GET）通过SSL发送。
答案 8 :(得分：-3)
您可以将密码作为MD5哈希参数发送，并添加一些盐。在服务器端比较它以获取身份验证。