评估：基于Web的应用程序中的奇数会话管理

Question

我一直在寻找具有基于Web的用户界面的遗留应用程序。考虑到它的年龄（将近10年的某些部分），有很多需要更新和重新设计，但我想知道关于用户会话如何工作的一个小问题。

简而言之：

• 整个用户界面都是通过HTTPS提供的。
• 通过将用户名和密码哈希值与保存在数据库中的值进行比较，可以非常有效地对用户进行身份验证。
• 在验证后，设置了一个浏览器cookie，其中包含两个值，用于保存用户访问过的最后一个顶级和第二个顶级部分/模块，一个到期日期以及一个值“loggedin = true” ”。注销后，cookie将以“loggedin = false”重置。 cookie中没有会话令牌。
• 身份验证后加载的第一个页面以及每个后续页面加载包含一个JavaScript变量“sessionToken”，它是一个base64编码的字符串，包含各种部分，其中一些加密：var sessionToken = "...."
• 每个导航链接通过<form>元素和JavaScript事件处理程序生成HTTP POST请求，并在后台传递相关变量以及sessionToken，而sessionToken又相同地设置，相同，在下一页加载。如果cookie在“loggedin = true”的同时，用户仍然保持登录状态，并且过期时间尚未过去。
• 会话在可配置的时间后过期。到期后，在下一次点击导航项目时会发生到期。我相信这只是通过比较会话令牌在后端写出的最后一次，但可能使用了cookie - 我还没有找到它。当会话过期时，cookie中的“loggedin”值将被翻转，用户将重定向到登录页面。

我不是安全专家，之前没有见过这个设计。我有兴趣知道你可以看到哪些陷阱和风险，如果有的话。 （我，我有一种不好的感觉，但想要更加坚实的意见。）

如果这是网络某个角落的标准方式，我也想听听它。

Answer 1

明显可以操纵Cookie，因此任何类似“loggedin = true”的身份验证都会引发一个标志，除非它被严格地用作导致对sessionid进行进一步身份验证检查的方法等。

注销时，应删除cookie，而不是设置为“loggedin = false”。

安全性似乎取决于sessionToken的内容。确保无法通过base64解码/重新编码更改重要信息（用户ID，管理员权限标志等）来分离和重新组合值。

完全通过表单提交导航并不完全是标准的会话方法。我建议将sessionToken移动到cookie。

Answer 2

Ian在他的回答中已经指出，依赖cookie值来表明用户的身份验证性质是不好的。我将重点关注会话cookie的管理方式。

会话cookie /令牌是唯一的，它们并不意味着泄露给其他用户。使用HTTPS可确保在应用程序中无法在线路上嗅探这些内容。但是，是否可以猜测会话令牌的值？如果是这样，你就有问题;现代应用程序依赖于安全框架来使用良好的PRNG生成会话cookie /令牌。如果您的应用程序不具有相似级别的随机性，则假设可以轻松推断会话令牌，从而使用户能够欺骗其他用户。

此外，在会话令牌的某些部分使用加密很有意思。这些部件的解密密钥是否安全管理？换句话说，密钥是硬编码的，还是恰好是每个安装一个密钥，或者是短生命周期随机生成的？如果密钥可以以任何方式猜测，推断或泄密，那么您或多或少会遇到相同的问题。

对会话密钥使用加密也可能使其容易受到填充oracle攻击，但我不确定这一点。更多细节会有所帮助。

我只是在这里猜测，因为我没有算法的确切细节，但仅仅使用HTTPS不需要授予任何安全感。我注意到了在野外服从数学序列的会话令牌。

最后，需要验证会话持续时间的硬配置限制的可用性和/或会话令牌到期的滑动窗口持续时间。否则，受损会话很可能会尽可能长时间存在，有时由于某些系统的性质而需要“物理”驱逐攻击者。

PS：还要验证用于密码的哈希算法;用盐很好。出于所有实际目的，MD5已被破坏。

使用自定义会话管理机制的含义

乍一看，在不使用cookie的情况下使用会话令牌似乎没有任何重大问题，但人们往往会失去一些在大多数平台上可用的安全功能 - cookie标记。安全和HttpOnly cookie标志降低了cookie在线路上被嗅探的风险（当客户端发送到服务器时），并且还确保客户端代码无法访问令牌，以后可能会被XSS攻击。因此，使用会话cookie比使用自定义会话令牌更好（在实现上很少或没有同行评审）。