使用 SSL 时在 URL 中传递用户名和密码的坏主意？答案

【问题标题】：Bad idea to pass username and password in the URL when using SSL?使用 SSL 时在 URL 中传递用户名和密码的坏主意？
【发布时间】：2011-06-20 13:40:09
【问题描述】：

场景：

我有一个带有 web 服务的 ASP.Net / Silverlight 网站，用于支持 Silverlight 应用程序的数据。该网站使用表单身份验证，因此 Web 服务也可以对请求进行身份验证。

现在我想从这个系统中提取一些数据到一个 Android 应用程序。我可以实现用于运行表单登录和存储身份验证 cookie 的代码，但实际上在 web 服务 url 中发送用户名和密码并验证每个调用会简单得多。我真的不认为这有什么大问题，因为通信是 SSL 加密的，但我愿意接受其他方式；）

你怎么看？坏主意/不是那么坏的主意？

结论：

在查看答案后，唯一真正有效的反对 name / pass in the url request string 的参数是它存储在服务器日志文件中。当然，这是我的服务器，如果该服务器被黑客入侵，它存储的数据也会被黑客入侵，但我仍然不喜欢密码出现在日志中。（这就是为什么它们被加盐和加密存储）

解决方案：

我将在请求中发布用户名和密码。最少的额外工作，更安全。

【问题讨论】：

【解决方案1】：

见Are querystring parameters secure in HTTPS (HTTP + SSL)?

所有内容都将被加密，但 URL 以及查询字符串（以及密码）将显示在服务器日志文件中。

【讨论】：

【解决方案2】：

坏主意：您的帖子内容已加密，尽管 URL 参数也可能已加密，但第三方跟踪器、服务器日志或其他一些监控软件仍然可以看到它们可以直接嗅探您的流量。以这种方式打开潜在的安全漏洞并不是一个好主意。

【讨论】：

URL的querystring部分由主机加解密，路由器唯一可见的部分是主机名
@Yaakov Ellis 有一个微妙的区别，因为 URL 上的参数是在 SSL 握手之后发送的，因此这些是加密的。见this post 和this one
很公平 - 但正如 dave.c 的第二个链接所指出的，任何第三方跟踪器都可以记录整个 url。服务器日志也将包含数据。
@Yaakov Ellis 我同意这是一个坏主意，我认为他应该实现 POST 登录并维护 cookie。真的没那么费劲。
SSL 是“防嗅探器”。如果您可以嗅探参数，您也可以嗅探帖子变量。跟踪器不是问题，因为网络服务器运行我制作的软件。浏览器历史不是问题，因为它会被原生 Android 应用程序使用。唯一有效的点是servelogs。尽管它是我控制的服务器，但我仍然不喜欢任何地方的明文密码，所以这就是我选择不走这条路的原因，而是使用 post 变量 insted。谢谢大家的意见！赞赏。

【解决方案3】：

用户确实倾向于直接从地址栏中复制并粘贴 URL 到电子邮件、博客等中，并将它们保存在书签等中。

诸如插件之类的东西，甚至其他读取窗口属性的软件（备用外壳、主题管理器、辅助软件）都可能以信息结尾。例如，他们可能会崩溃并自动将故障转储发送回他们的开发人员。

而且远没有 keloggers 复杂的蠕虫——比如需要屏幕转储的东西——可以通过这种方式获取密码。有时甚至是安全软件，例如部署在公司网络中。

如果用户有一个本地代理，那么他们可能会与代理进行纯文本通信，而代理又会使用 SSL 进行通信（不是应该的方式，但它确实发生了）。

由于这些以及更多的原因，过去是标准的带有用户名和密码的 URL - 例如在权限段中带有用户名和密码的 ftp URL - 现在通常被浏览器禁止。

所以，强调不，不要这样做。

【讨论】：

【解决方案4】：

不提供用户名和密码等敏感信息始终是一种很好的编程习惯在网址中。无论网站有多好，它都可能受到损害。那么为什么要提供更多信息呢？

【讨论】：