将会话 ID 作为 url 参数传递的危害

Posted 2023-02-19

【中文标题】将会话 ID 作为 url 参数传递的危害

【英文标题】：Harm of passing session id as url parameter

【发布时间】：2015-02-14 11:44:51

【问题描述】：

所以我刚刚注意到其中一个互联网银行网站正在将会话 ID 作为 url 参数传递。 （见下图）

我以前没有在任何地方看到';'在 url 中，在这种情况下，它位于“private;”之后。

1) 这个';'有什么用？

2) 为什么需要在互联网上最安全的地方的互联网银行将会话 ID 作为 url 参数传递？

起初，我认为他们这样做是因为某些用户不允许使用 cookie，但话又说回来，如果他们允许，请使用 cookie，如果不是 - url，但我确实允许使用 cookie，所以显然就是这样不是这样的。

3) 我想他们应该有一些其他的安全措施？它们可能是什么？

4) 如果他知道其他人的有效会话 ID，他可能会做什么？ 据我所知，如果你知道那个 id，你可以很容易地登录到其他人的会话，因为编辑 cookie 并不难，而且更容易将该会话 id 作为 url 参数传递，特别是如果你有类似的东西：

session_id($_GET[sessionid]);

谢谢！

【参考方案1】：

将会话信息存储在 cookie 或 URL 中都是可行的方法。组合可以用作 安全会话管理和（服务器）会话管理是不同的方面：

根本区别在于 cookie 在浏览器窗口/选项卡之间共享，而 url 不是。

如果您希望您的用户在导航到不同选项卡中的同一站点时登录，共享安全会话（=无需新的登录过程），那么 cookie 是一个好方法。

为了区分每个选项卡的“会话”并将不同的服务器会话与不同的选项卡相关联（想想用户在两个不同的选项卡中并行运行两个“有状态”事务），在客户端上管理每个选项卡可能不同的 sessionId 是必需的。 Cookie 在这里不起作用。

将它放在 URL 中是确保此信息定期添加到从页面（引荐来源标头）触发的请求中的一种方法。替代方法需要特定的代码来明确地将这些信息添加到每个请求中，这需要更多的工作。

见How to differ sessions in browser-tabs?

【参考方案2】：

这个;有什么用？

这只是一个查询字符串分隔符。 & 不是 URL 规范 (RFC 3986) 中指定的唯一 sub-delim。

为什么需要在互联网上最安全的地方的互联网银行将会话 ID 作为 url 参数传递？

可能从未使用过此会话 ID，而实际会话标识符用户是在 cookie 或每个导航页面之间的 POST 数据中传递的。验证这一点的唯一方法是尝试将 URL 复制到另一个浏览器中，以查看您的会话是否已恢复，但是他们可能会再次检查 User Agent 之类的内容 - 不是真正的安全性，但会阻止随意攻击。 不要在您没有权限的实时系统上尝试此操作，因为这样做是非法的。如果您想了解安全性，请下载 Hacme Bank 之类的内容并在那里尝试。

我想他们应该有其他一些安全措施？它们可能是什么？

毫无疑问，他们会这样做，否则这将是一个巨大的安全威胁。如果页面上有任何外部链接，则 URL 可能会在 referer 标头中泄露。银行为其网站使用的安全类型太大，无法在此处列出，但它们应符合某些行业标准，例如 ISO/IEC 27001，这将涵盖其网站需要防范的威胁类型。

如果他知道其他人的有效会话 ID，他还能做什么？据我所知，如果您知道该 id，您可以很容易地登录到其他人的会话，因为编辑 cookie 并不难，并且更容易将该会话 id 作为 url 参数传递，特别是如果您有类似的东西：

由于 ID 显示在屏幕上，因此可以读取它（尽管 ID 通常很长）。更现实的攻击是Session Fixation。这是攻击者可以设置受害者的会话 ID 的地方。例如，向他们发送包含攻击者会话 ID 的链接。当受害者跟随它然后登录时，由于攻击者具有相同的会话，因此他们也已登录。

【参考方案3】：

所以，@Amadan 正确地涵盖了 #1 和 #4。但还有一点需要扩展。

在 URL 中使用会话标识符可能是一个主要问题。有一些情况非常糟糕：

会话劫持：

如果用户将 URL 复制粘贴到电子邮件中。

在这种情况下，攻击者可以简单地阅读电子邮件，并窃取会话标识符（从而恢复会话）。

您可以通过缩短会话生命周期并验证会话中的 IP 地址或用户代理等内容来部分防御这种情况。请注意，这些都不是万无一失的，它们只会使其“稍微”难以攻击。

如果连接曾经降级为 HTTP。

如果他们没有使用Http-Strict-Transport-Security (HSTS)，那么攻击者可能能够成功地将会话降级为仅 HTTP（通过 MITM 样式攻击）。如果服务器没有完美地设置，这可能会导致 URL 泄露给攻击者，从而泄露会话标识符。

会话固定攻击

攻击者可以制作会话标识符，并向用户发送带有该会话标识符的伪造链接。用户然后登录到该站点，会话现在与他们的帐户绑定。

您可以通过在每次会话更改（登录、注销、权限升级或降级等）时严格轮换会话标识符来缓解这种情况。但许多服务器不这样做，因此容易受到固定式攻击。

cookie 会话被视为更安全的原因是不是，因为它们更难编辑。这是因为它们更能抵抗固定攻击（您不能创建 URL、链接、表单或 js 或代表用户发送欺诈性 cookie 的任何东西）。

为什么银行使用 URL 参数？我有两个猜测：

因为他们想支持那些不允许使用 cookie 的人。

值得叹息。

他们不知道更好。

说真的。如果它不在合规文档或 NIST 建议中，那么他们可能不会这样做。见鬼，已经实施的 NIST 建议被认为是不安全的，但仍然被遵循，因为它是书面的。

【参考方案4】：

1) 您应该询问红框所覆盖的应用程序的设计者。 URL 可以是任何你想要的； key=value&key2=value2 的约定就是这样 - 约定。在这种情况下，它是 Java，它通常使用 ;jsessionid=.... 的约定作为其 SID。

2) 这不是什么大事。普通用户不能像复制粘贴 GET 参数那样复制粘贴 cookie，但高级用户可以做任何他们想做的事（使用 Mechanize、wget、curl 和其他非浏览器方式，甚至浏览器扩展） .而且，如果您允许某些用户使用它而不允许某些用户使用它，那么这并不是真正的安全预防措施，是吗？基本上，cookie SID 会使攻击更加困难，但这就像把你的前门钥匙放在垫子下面——绝对不能保证你的门安全。此外，cookie 在选项卡之间共享：如果网站希望您同时使用两个帐户登录，您无法使用 cookie。

3) 服务器端安全，是的。一种有效的对策是一次性 SID（每次访问页面时，服务器从当前 SID 读取会话，然后使用新 SID 为下一个请求启动新会话）。一个不太有效但仍然很好的方法是验证其他信息的一致性（例如 - 仍然是相同的 IP？仍然是相同的浏览器？）

4) 是的，如果您知道某人的有效 SID，并且服务器不能充分防止会话固定，您可以“成为”那个人。例如，这可能使攻击者能够用你的钱支付账单。

【讨论】：

感谢您的回答。他们真的有助于理解:) 你知道任何关于会话安全的有用链接，尤其是一次性 SID（我从未听说过）吗？

抱歉，暂时没有。 Google 用于“会话固定”和“一次性 cookie”。