将会话 ID 作为 url 参数传递真的不安全吗？

虽然它本质上不是不安全的，但除非代码设计得非常好，否则它可能会成为一个问题。

假设我访问了我最喜欢的论坛。它让我登录并将我的会话 ID 附加到每个请求中的 URL。我找到了一个特别有趣的话题，并将 URL 复制并粘贴到即时消息中给我的朋友。

除非应用程序已采取措施确保对会话 ID 进行某种形式的验证，否则单击该链接的朋友可能会继承我的会话，然后就可以像我一样做任何我能做的事情。

通过将会话标识符存储在 cookie 中，您可以完全消除链接共享问题。

这个主题有一个变体，称为会话固定，它涉及出于恶意目的故意共享会话标识符。链接的 Wikipedia 文章深入介绍了这种攻击的工作原理以及它与无意共享会话标识符的区别。

为什么 cookie 更安全？

Cookie在这里可以更安全，因为它们不是普通用户可以复制和粘贴，甚至查看和修改的东西。它们是一个更安全的默认值。

攻击者对这两种选择都有哪些可能性？

这两种方法都不安全，不会受到未加密通信的中间人攻击。浏览器插件、间谍软件和其他客户端恶意软件也可以监视两种存储会话标识符的方法。

在这两种情况下，声称拥有会话 ID 的客户端的服务器端验证都是最佳实践。这个验证是由什么组成的有待讨论。请记住，公司代理背后的用户可能会在请求之间在 IP 地址之间跳转，因此将会话锁定到 IP 地址可能会意外疏远人们。会话固定文章提到了其他一些有用的替代方案。

大多数网站将其用户的登录状态存储到会话中，如果攻击者拥有会话 id，他也获得了登录用户的权限。换句话说，维护会话和身份验证这两个关注点经常是耦合的。

一个问题是，很容易进行会话固定攻击。在这种情况下，攻击者会向用户发送带有已知会话 ID 的准备好的 URL。如果用户单击此 URL 并进行登录，则攻击者将拥有一个具有特权的会话。如果网站需要 cookie，那么电子邮件中准备好的 URL 是不够的。

如果站点使用 HTTP 和 HTTPS 混合，则 id 将在所有 HTTP 请求（即使是图像请求）的 URL 中以纯文本形式传输。因此，如果攻击者可以在用户登录后读取单个 HTTP 请求，他就知道会话 id。

解决这个问题的一种方法是将这两个问题分开，维护会话和身份验证。然后，您可以使会话 ID 不受保护，仅用于维护会话，并使用单独的 cookie 来检查登录状态。此 cookie 必须配置为仅发送到 HTTPS 页面。

除了 Charles 和 Martin 所说的之外，在 URL 中添加任何内容都会使其更有可能泄漏。这可以通过链接资源中的 Referer 标头，从访问具有浏览器历史记录的端点，从暴力历史嗅探，不当保护的 Web 日志等。因此，通常不建议将您想要保密的任何内容放在 URL/查询字符串中。

我没有看到 PayPal 在 URL 中使用服务器会话 ID。没有办法真的比 cookie 更安全。过去通常这样做的原因是支持未启用 cookie 的浏览器。这些天来，这个问题越来越少，除了会话固定攻击之外，不共享链接的可用性问题意味着今天通常避免使用 URL 中的会话。

几年前我看到有人将一个 URL（带有 sessionid）复制到 twitter 中。然后，所有关注者都可以完全访问该网站上的那个人的帐户。

所以是的，在 URL 中放置 sessionID 是个坏主意。