即使用了 https 也不要通过 query strings 传敏感数据

（给前端大全加星标，提升前端技能）

编译：伯乐在线/xiaoheike

服务器端的 log 将明文记下完整 url；浏览器上的访问历史也会明文记下完整 url；Referrer headers 里也忠实记下完整 url，然后在别人家的 Google Analytics 上显示。

我们经常听到的一个常见问题是：“URL 中的参数是否可以安全地传递到安全网站？”这个问题常常出现在客户看了 HttpWatch 捕获的 HTTPS 请求后，想知道还有谁可以看到这些数据。

例如，假设在一个查询中，使用如下安全的 URL 传递密码字符串：

https://www.httpwatch.com/?password=mypassword

HttpWatch 能够显示安全请求的内容，因为它与浏览器集成，因此它能够在 HTTPS 请求的 SSL 连接对数据加密之前查看数据。

如果你使用网络嗅探器查看，例如 Network Monitor，对于同一个请求，你只能够查阅加密之后的数据。在数据包跟踪中没有可见的网址，标题或内容：

您可以信任 HTTPS 请求是安全的，只要：

• 未忽略任何SSL证书警告

• Web 服务器用于启动 SSL 连接的私钥在 Web 服务器本身之外不可用。

因此，在网络层面，URL 参数是安全的，但是还有一些其他基于 URL 泄漏数据的方法：

1. 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:

2. URL 存储在浏览器历史记录中–即使安全网页本身未缓存，浏览器也会将 URL 参数保存在其历史记录中。以下是 IE 的历史记录，显示了 URL 的请求参数：

   
   

   

如果用户创建书签，查询字符串参数也将被存储。

1. URL 在 Referrer 请求头中被传递–如果一个安全网页使用资源，例如 javascript，图片或者分析服务，URL 将通过 Referrer 请求头传递到每一个嵌入对象。有时，查询字符串参数可能被传递并存放在第三方站点。在 HttpWatch 中，你可以看到我们的密码字符串正被发送到 Google Analytics：

结论

解决这个问题需要两步：

• 只有在绝对必要的情况下传递敏感数据。一旦用户被认证，最好使用具有有限生命周期的会话 ID 来标识它们。

使用会话层级的 cookies 传递信息的优点是：

• 它们不会存储在浏览器历史记录中或磁盘上

• 它们通常不存储在服务器日志中

• 它们不会传递到嵌入式资源，例如图片或 JavaScript 库

• 它们仅适用于请求它们的域和路径

以下是我们的在线商店中，用于识别用户的 ASP.NET 会话 cookie 示例：

请注意，cookie 被限制在域 store.httpwatch.com，并且在浏览器会话结束时过期（即不会存储到磁盘）。

你当然可以通过 HTTPS 传递查询字符串，但是不要在可能出现安全问题的场景下使用。例如，你可以安全的使用它们显示部分数字或者类型，像 accountview 或者 printpage，但是不要使用它们传递密码，信用卡号码或者其他不应该公开的信息。

推荐阅读

（点击标题可跳转阅读）

HTTPS 到底加密了什么？

强推 HTTPS 见效？Google 表示 HTTPS 使用率不断升高

Chrome 新动作：取消 HTTPS 页面安全标记；暂时恢复网页自动播放功能

觉得本文对你有帮助？请分享给更多人

关注「前端大全」加星标，提升前端技能