HTTPS查询字符串是否安全?

是的,是的。 但对敏感数据使用get是个坏主意 原因如下:

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

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

[1]尽管我需要注意的是,RFC声明浏览器不应该将引用者从HTTPS发送到HTTP。但这并不意味着一个糟糕的第三方浏览器工具栏或来自HTTPS站点的外部图像/闪存不会泄漏它。

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

因此,最好至少对密码对话框使用POST。另外,正如Littlegek发布的链接所指出的那样,GET URL更可能被写入服务器日志。

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

原因是查询字符串是 HTTP 协议是应用层协议,而安全 (SSL/TLS) 零件来自运输层。这个 SSL 首先建立连接,然后将查询参数(属于HTTP协议)发送到服务器。

当建立 SSL 连接时,客户端将按顺序调用以下步骤。假设您试图登录名为 范例网站 并希望使用查询参数发送凭据。你完成 URL 可能如下所示。

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

1. 您的客户端(例如:浏览器/移动应用程序)将首先解析您的域名 (example.com) 对 IP 地址 (124.21.12.31) 使用A DNS 请求。查询该信息时,只使用特定于域的信息。仅IE example.com 将被使用。
2. 现在,您的客户端将尝试使用 知识产权 地址 124.21.12.31 并尝试连接到端口 443 ( SSL 服务端口不是默认端口 http 港口 80 )
3. 现在,服务器 范例网站 将其证书发送给您的客户端。
4. 您的客户端将验证证书并开始为您的会话交换共享密钥。
5. 成功建立安全连接后,只有通过安全连接发送查询参数。

因此,您不会公开敏感数据。但是,使用此方法通过HTTPS会话发送凭据不是最佳方法。你应该换一种方法。

对。HTTPS会话的整个文本由SSL保护。包括查询和头。在这方面,一个帖子和一个GET是完全一样的。

至于你的方法的安全性,没有适当的检查就没有真正的方法可以说。

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

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

可以将代理配置为“中间人”。基本上,浏览器向代理发送连接到真实服务器的请求。如果代理是这样配置的,它将通过SSL连接到真正的服务器,但浏览器仍将与代理进行对话。因此,如果攻击者能够访问代理,那么他可以以明文形式查看流经代理的所有数据。

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

最后,可能有人入侵了你的电脑,安装了键盘记录器或屏幕刮刀(很多特洛伊木马病毒都是这样)。由于密码直接在屏幕上可见(与密码对话框中的“*”相反),这是另一个安全漏洞。

结论:在安全问题上,始终要走老路。有太多你不知道,不会想到,会折断你的脖子。

是的,只要没有人从你肩上看显示器。

我不同意关于 […]HTTP引用泄漏(目标页中的外部图像可能泄漏密码) 在里面 Slough's response .

HTTP 1.1 RFC explicitly states :

客户不应包括引用者 (非安全)HTTP中的头字段 如果引用页是 用安全协议传输。

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

是的,从您建立HTTPS连接的那一刻起,任何时候都是安全的。通过SSL发送POST时的查询字符串(GET)。

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