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

Question

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

我之前没有看到过';'在url中，在这种情况下它位于'private;'之后。

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

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

起初，我认为他们这样做是因为有些用户不允许使用cookie，但是如果他们允许的话，再次使用cookies，如果不是 - url，但我允许使用cookie，所以很明显不是这样的。

3）我猜他们应该采取其他一些安全措施吗？他们可能是什么？

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

session_id($_GET[sessionid]);

谢谢！

Answer 1

1）您应该询问红盒子所覆盖的应用程序的设计者。 URL可以是您想要的任何内容; key=value&key2=value2的惯例就是 - 一个惯例。在这种情况下，它是Java，它通常使用;jsessionid=....的约定作为其SID。

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

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

4）是的，如果您认识某人的有效SID，并且该服务器没有充分防止会话固定，您可以＆＃34;成为＆＃34;那个人。例如，这可能使攻击者用你的钱支付他的账单。

Answer 2

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

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

1. 会话劫持：

   如果用户将网址粘贴到电子邮件中。

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

   您可以通过缩短会话生命周期并在会话中验证IP地址或用户代理等内容来部分防范此问题。请注意，这些都不是万无一失的，他们只是轻轻地做到了＃34;更难攻击。

2. 如果连接被降级为HTTP。

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

3. 会话固定攻击

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

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

Cookie会话被视为更安全的原因是不，因为它们更难编辑。这是因为他们更能抵御录制攻击（您无法代表用户创建URL或链接或表单或js或任何发送欺诈性cookie的内容）。

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

1. 因为他们想要支持那些不允许使用cookies的人。

   叹气值得。

2. 他们不知道更好。

   严重。如果它不在合规性文档或NIST推荐中，那么他们可能不会这样做。地狱，已经实施了NIST的建议，这些建议被认为是不安全的，但仍然被遵循，因为它是书面形式。

Answer 3

  

这个;有什么用？

这只是一个查询字符串分隔符。 &不是网址规范（RFC 3986）中指定的唯一sub-delim。

  

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

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

  

3）我猜他们应该采取其他一些安全措施吗？他们可能是什么？

毫无疑问他们会，否则这将是一个巨大的安全威胁。如果页面上有任何外部链接，则URL可能会泄漏到referer标题中。银行用于其网站的安全类型太大而无法在此列出，但是它们应该符合某些行业标准，例如ISO/IEC 27001，这些标准将涵盖其网站需要保护的威胁类型。< / p>

  

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

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

Answer 4

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

根本区别在于浏览器窗口/标签之间共享Cookie，网址不是。

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

区分＆＃34;会话＆＃34;每个选项卡并将不同的服务器会话与不同的选项卡相关联（想想用户在两个不同的选项卡中并行运行两个＆＃34;有状态＆＃34;事务），管理客户端上的sessionId，每个选项卡可能不同。饼干在这里不起作用。

将其放入URL是确保将此信息定期添加到从页面触发的请求（引用者标题）的一种方法。替代方法需要特定代码才能将此信息明确地添加到每个请求中，这是更多的工作。

请参阅How to differ sessions in browser-tabs?