HTTPS查询字符串是否安全？

我正在创建一个使用HTTPS的安全的基于Web的API; 但是,如果我允许用​​户使用查询字符串配置它(包括发送密码)这也是安全的,还是应该通过POST强制它？

1> dr. evil..：

---

是的.但是,对于敏感数据使用GET是一个坏主意,原因如下:

主要是HTTP引用者泄漏(目标页面中的外部图像可能泄漏密码[1])

密码将存储在服务器日志中(显然很糟糕)

浏览器中的历史缓存

因此,即使Querystring受到保护,也不建议通过查询字符串传输敏感数据.

[1]虽然我需要注意RFC规定浏览器不应该将引用从HTTPS发送到HTTP.但这并不意味着糟糕的第三方浏览器工具栏或来自HTTPS站点的外部图像/闪存不会泄漏它.

---

那么*https到https*推荐人怎么样？如果我使用https从第三方网站获取图像？浏览器会将我之前请求的整个查询字符串发送到第三方服务器吗？

---

@ Jus12是的,它没有意义,但这就是它的设计方式.

---

那么为什么不建议OAuth2规范在查询参数中发送敏感数据(在URL中)？即使建议始终使用TLS(HTTPS).请参阅http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-16#section-4.3 CC @volka中的最后一点

2> VolkA..：

---

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

因此,首选使用post至少用于密码对话框.同样如链接中指出的那样,littlegeek发布的GET URL更有可能被写入您的服务器日志.

3> Ruchira Rand..：

---

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

背后的原因是查询字符串example.com是作为应用层协议的协议的(124.21.12.31)一部分,而安全部分来自传输层.的example.com连接建立第一和然后查询参数(属于http协议)发送到服务器.

建立124.21.12.31连接时,您的客户将按顺序调用以下步骤.假设您正在尝试登录名为example.com的站点,并希望使用查询参数发送您的凭据.您的完整内容example.com可能如下所示.

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

您的客户(例如:浏览器/移动应用)将首先使用请求将您的域名解析example.com为(124.21.12.31)地址.查询该信息时,仅使用特定于域的信息.即:仅使用.example.com124.21.12.31example.com

现在,您的客户端将尝试使用该example.com地址连接到服务器,(124.21.12.31)并尝试连接到端口example.com(124.21.12.31服务端口而不是默认example.com端口example.com).

现在,服务器(124.21.12.31)将其证书发送给您的客户端.

您的客户端将验证证书并开始为您的会话交换共享密钥.

成功建立安全连接后,只有通过安全连接发送查询参数.

因此,您不会暴露敏感数据.但是,使用此方法通过https会话发送凭据不是最佳方法.你应该采取不同的方法.

---

zaph，在HTTPS安全性方面，目标是将数据安全地发送到服务器，而中间的任何人都无法嗅探数据。尽管这是可能的，并且可以回答问题，但实际上很难控制服务器之后的工作。这就是为什么我也提到这不是正确的方法。除此之外，您永远不要从客户端发送您的密码。您应该始终在设备上对其进行哈希处理，然后将哈希值发送到服务器。

---

但是请参阅@dr的答案。邪恶的是，quarry字符串可能最终出现在日志文件和缓存中，因此在服务器上可能不安全。

4> shoosh..：

---

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

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

---

安全性不仅仅是浏览器和服务器之间的通信

5> Aaron Digull..：

---

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

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

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

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

最后,有人可能已经攻击了您的计算机并安装了键盘记录器或屏幕刮板(以及许多特洛伊木马类型的病毒).由于密码直接在屏幕上可见(而不是密码对话框中的"*"),这是另一个安全漏洞.

结论:在安全方面,总是依赖于人迹罕至的道路.有太多你不知道,不会想到,哪个会打破你的脖子.

---

"浏览器仍将与代理通信"不完全正确,它需要向浏览器提供一个有效的证书,代理只有在控制浏览器信任的CA时才能生成该证书.

6> Ali Afshar..：

---

是的,只要没有人在监视器上看着你的肩膀.

---

和你的浏览器没有保存历史记录:)

7> Arnout..：

---

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

HTTP 1.1 RFC 明确指出:

如果引用页面是使用安全协议传输的,则客户端不应在(非安全)HTTP请求中包含Referer头字段.

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

---

@Arnout:请阅读此RFC,它告诉你什么不应该意味着:http://www.ietf.org/rfc/rfc2119.txt它不一样,所以你引用的部分并不是真正的相关和浏览器代理可能仍包含HTTP的引用程序.

---

那个词应该再次"应该".您是否相信每个浏览器的每个版本都带有您的密码？

---

此外,HTTPS网页可能正在通过HTTPS*检索外部图像* - 在这种情况下,浏览器应该包含引用标头,从而暴露您的密码......

8> Drejc..：

---

是的,从建立HTTPS连接的那一刻起,每个人都是安全的.作为POST的查询字符串(GET)通过SSL发送.