服务器端的 log 将明文记下完整 url;浏览器上的访问历史也会明文记下完整 url;Referrer headers 里也忠实记下完整 url,然后在别人家的 Google Analytics 上显示。
我们经常听到的一个常见问题是:“URL
中的参数是否可以安全地传递到安全网站?”这个问题常常出现在客户看了 HttpWatch
捕获的 HTTPS
请求后,想知道还有谁可以看到这些数据。
例如,假设在一个查询中,使用如下安全的 URL
传递密码字符串:
https://www.httpwatch.com/?password=mypassword
HttpWatch
能够显示安全请求的内容,因为它与浏览器集成,因此它能够在 HTTPS
请求的 SSL
连接对数据加密之前查看数据。
如果你使用网络嗅探器查看,例如 Network Monitor
,对于同一个请求,你只能够查阅加密之后的数据。在数据包跟踪中没有可见的网址,标题或内容:
您可以信任 HTTPS
请求是安全的,只要:
因此,在网络层面,URL
参数是安全的,但是还有一些其他基于 URL
泄漏数据的方法:
URL
存储在 Web 服务器日志中–通常每个请求的完整 URL
都被存放在服务器日志中。这意味着 URL
中的任何敏感数据(例如密码)会以明文形式保存在服务器上。以下是使用查询字符串通过 HTTPS
发送密码时存储在 httpwatch.com
服务器日志中的条目: **2009-02-20 10:18:27 W3SVC4326 WWW 208.101.31.210 GET /Default.htm password=mypassword 443 … 通常认为即使是在服务器上,存储明文密码从来都不是好想法2.URLs are stored in the browser history – browsers save URL parameters in their history even if the secure pages themselves are not cached. Here’s the IE history displaying the URL parameter:URL
存储在浏览器历史记录中–即使安全网页本身未缓存,浏览器也会将 URL
参数保存在其历史记录中。以下是 IE
的历史记录,显示了 URL
的请求参数:
如果用户创建书签,查询字符串参数也将被存储。
URL
在 Referrer
请求头中被传递–如果一个安全网页使用资源,例如 javascript
,图片或者分析服务,URL
将通过 Referrer
请求头传递到每一个嵌入对象。有时,查询字符串参数可能被传递并存放在第三方站点。在 HttpWatch
中,你可以看到我们的密码字符串正被发送到 Google Analytics
:结论
解决这个问题需要两步:
ID
来标识它们。使用会话层级的 cookies
传递信息的优点是:
JavaScript
库以下是我们的在线商店中,用于识别用户的 ASP.NET
会话 cookie
示例:
请注意,cookie
被限制在域 store.httpwatch.com
,并且在浏览器会话结束时过期(即不会存储到磁盘)。
你当然可以通过 HTTPS
传递查询字符串,但是不要在可能出现安全问题的场景下使用。例如,你可以安全的使用它们显示部分数字或者类型,像 accountview
或者 printpage
,但是不要使用它们传递密码,信用卡号码或者其他不应该公开的信息。