security - 无休止的 session : any security risk?

Question

我正在开发的一款旧版应用程序让用户填写大量问题，并在问卷的最后批量保存答案。这个过程很长，一个典型的用户可能会在某个时候超时。

团队想出了一个无休止的 session 来绕过这个问题的想法。经过一番谷歌搜索后，我发现了许多解释如何增加超时的文章；但是，我没有遇到暴露这种做法风险的文章。乍一看，我觉得设置超时是合理的。

我的问题是:

• 您是否认为无休止的 session 可能会带来安全风险？
• 如果是这样，这种做法会带来哪些典型风险？

Answer 1

主要风险是如果 session 标识符永不过期，它实际上会成为密码。任何有权访问 session 标识符的人都可以离线记录，然后在以后使用它来登录应用程序。例如，有人可以从 cookie 中复制 session token ，并短暂访问用户的机器。

对此的缓解方法是定期轮换 session 标识符。也许您可以有一个每 10 分钟触发一次的 AJAX 请求并为当前 session 获取一个新 token - 即使使用标准 session 到期时间(例如 10-20 分钟)，这也足以让 session 保持事件状态在提交表单之前不会超时。

暴力破解不是问题:只要 session 标识符有足够的熵，那么暴力破解的风险就很小。 OWASP guidance here on selecting a strong method for session identifier generation .

在性能方面比安全方面更重要的是，如果您为每个 session 将对象存储在内存中，那么最终内存将随着 session 数量的增加而被填满。

长 session 的另一个风险是任何 CSRF 或 XSS 漏洞都有很长的暴露时间以被利用。如果用户访问了针对您的应用的恶意站点，短 session 超时将减轻任何攻击，因为用户不会通过身份验证。即使使用持久登录，如果您的站点被充分锁定(例如，它只允许具有 CSRF 保护的请求本身用刷新 token 交换访问 token )。

例如，如果存在 CSRF 漏洞:

[User]   --> [Attacker's Site]                          --> [Your site]

Browser  --> Malicious Page builds form for your site   --> Submits form via AJAX

由于 session 超时无休止，如果用户曾经使用浏览器访问过您的网站，此攻击就会成功。

但是，如果您有两个 session token :一个刷新 token 和一个访问 token ，并且您需要一个访问 token 来提交表单，这将阻止攻击。由于访问 token 只能由同一站点请求检索，因此确保该请求的处理程序受到足够的保护以免受 CSRF 的影响将减轻您站点上可能存在的其他漏洞。

因此，如果您必须使 session 无限，请使用必须交换的不同 token 才能通过您的网站进行身份验证。见 this post了解如何实现“记住我”功能(也就是我们的刷新 token )。缺点是您必须自己实现刷新 token 才能访问 token 逻辑，并要求用户必须再次使用访问 token 重新发送任何请求(这可以通过 JavaScript 使用客户端逻辑来实现)。