使用敏感数据发布HTTPS GET请求的安全隐患

时间:2011-08-03 15:02:27

标签: security url https

对URL中的敏感数据进行HTTPS / SSL GET操作是否存在安全隐患?这将在IIS日志中以明文形式记录吗?可以在开放的WiFi接入点上嗅探网络流量请求吗?

即。 https://www.websiteurl.com/get.aspx?user=user&password=password

3 个答案:

答案 0 :(得分:5)

问题在这里得到了更好的回答:Are https URLs encrypted?

  1. 网址已加密。
  2. 但是,明文可能会很好地显示在目标服务器的日志中,因为服务器将对其进行解密,并根据设置将值存储在日志中。
  3. 唯一可以嗅探的部分是dns部分。在这种情况下www.websiteurl.com
  4. 那说你最好不要在查询字符串上使用带有用户名/ pw的get请求。

    修改 我想补充一点。

    1. 浏览器历史记录中提供了GET请求的完整未加密网址。如果某些东西能够嗅探浏览器历史记录,那么它就可以完全访问查询字符串中的内容。
    2. HTTP Referrer问题。如果用户单击指向其他站点的链接,则可以将URL提交到第三个站点。
    3. 在#2和#4之间,使用敏感数据的查询字符串是不明智的。

答案 1 :(得分:3)

HTTPS是 SSL / TLS之上的HTTP 。这意味着HTTP交互的全部内容(包括URL)都是加密的。只有网络级信息(如服务器的IP地址和端口)未加密。 See HTTPS on wikipedia.

然而,与此同时,这只是 网络级别的安全性 - 无论接收请求的任何Web服务器都将解密它(并且可能将其留在日志中),然后再将其传递给任何托管的Web应用程序如果您选择使用基本身份验证,HTTPS会保护最明显的问题(以明文形式发送密码),但它有some other issues

您提到这是在两个系统之间交换的数据,我认为这意味着您正在实现连接的客户端。在这种情况下,无论您如何发送数据(GET / POST / headers / etc.),您都需要格外小心,以验证您要连接的机器的SSL证书。如果中间人可以让你根据他的密钥而不是你信任的服务器的密钥加密数据,那么加密敏感数据根本无济于事。这是huge source of vulnerabilities

答案 2 :(得分:1)

与我写的here相同。不是一个好主意,浏览器缓存URL,易受社会工程影响,它出现在服务器日志中......

改为使用POST或基本身份验证。