无休止的会话：任何安全风险？答案

【问题标题】：Endless session: any security risk?无休止的会话：任何安全风险？
【发布时间】：2016-06-20 00:51:02
【问题描述】：

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

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

我的问题是：

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

【问题讨论】：

标签： security session

【解决方案1】：

无限会话本质上并不比您的会话实现安全性低，但它确实允许攻击者有更多时间进行利用。例如，对于无休止的会话，会话劫持变得容易一些，因为攻击者有无限的时间。它还允许对会话进行暴力破解，但鉴于生成的会话令牌足够复杂，这也不应该成为问题。

基本上，它可以/将使现有漏洞更容易被利用，但不会削弱实现本身。

【讨论】：

【解决方案2】：

会话超时的主要原因是能够在某个时候删除与会话关联的任何服务器端存储数据。否则，您的会话存储将始终增长，并且您将永远无法在某个时候删除任何存储的数据。

当然，会话持续的时间越长，攻击者就越有可能猜测会话的 ID 并劫持它。但这可以通过不时更改会话 ID 轻松缓解。

【讨论】：

【解决方案3】：

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

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

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

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

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

例如，如果存在 CSRF 漏洞：

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

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

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

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

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

【讨论】：

你在混淆一些东西：X-Frame-Options是为了防止点击劫持；相同的来源政策已经适用于框架。
抱歉，如果我没有说清楚。是的，这两件事就是这样做的。但是不同的是，如果浏览器启用了第三方 cookie，则浏览器可以在 iframe 中读取新 cookie，而由于 SOP，它不能在 XHR 中读取。
SOP 以同样的方式应用于帧。文档如何能够从不同来源的框架文档中读取 cookie？
Post 澄清了一种更好的方法来实现这一点，而无需涉及 SOP 或 IFrame。