没有 cookie 的安全会话管理

Posted 2023-03-08

【中文标题】没有 cookie 的安全会话管理

【英文标题】：secure session management without cookies

【发布时间】：2016-05-05 10:28:12

【问题描述】：

几个月前，我参观了一个安全研讨会，我们讨论了使用 cookie 进行会话管理时的一些安全问题。 有人告诉我，cookie 最初不是为处理会话而设计的。 但是那应该怎么做呢？

【参考方案1】：

Cookie 仍然是会话管理的最佳方式。请注意 cookie 的限制。为获得更好的结果，请使用无法通过 http 传输的Secure Cookies，仅使用 https。这些内容更难意外泄漏，例如，如果页面上有对不安全图像的引用。

【讨论】：

感谢您的提示。但是没有 cookie 怎么能完成会话管理呢？

您可以在 URL 中放置会话密钥。然而，这通常被认为是非常糟糕的做法，并且存在众所周知的安全问题。另一个非常不同的选择是在客户端做所有事情，例如使用 javascript，并保持服务器无状态 - 例如使用 REST API。其优点是服务器保持简单，并且更容易确保其安全。另一方面，这意味着使用 Javascript 进行编程，这对于没有错误的代码来说并不是一个很好的选择。

【参考方案2】：

执行此操作的安全方法是生成一个加密随机 128 位值（即由 CSPRNG 生成的随机值），然后将其作为 POST 数据传递到每个页面。

例如

<form method="post" action="/globalHandler">
  <input type="hidden" name="sessionId" value="<sessiontoken>" />
  <input type="hidden" name="page" value="accountDetails" />
</form>

优点是会话标识符永远不需要在 cookie 中传输，从而减轻了诸如 POODLE 或 BREACH 之类的 SSL 攻击（攻击者无法注入请求，因为它们没有会话标识符）。这也从本质上防止了CSRF 攻击。

缺点是登录时要访问的每个页面都只能通过 POST 方法访问，其中可以在 sessionId 参数上进行适当的验证。因此，最好在第一次开发网站时对其进行处理，而不是更改现有网站以适应这种格式。

使用 POST 数据比 GET 更安全，因为使用 GET，详细信息将位于 URL 的查询字符串部分。例如

https://example.com?sessionId=1234...

这不仅使会话标识符在用户屏幕上可见，而且还可以通过引用标头泄漏，并且默认情况下还会记录在浏览器历史记录、代理和服务器日志中。默认情况下很少记录 POST 数据。

一些银行使用这种方法来确保用户在他们的会话期间只有一个活动路径 - 会话标识符可以很容易地轮换，这样如果用户走不同的路线，他们的标识符就会不匹配并且他们被注销。当您有一个必须以固定顺序执行的多步骤过程时，从安全的角度来看，这很有用。当用户采用与开发人员预期不同的路径时，可能会出现一些业务逻辑漏洞。