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

Question

我一直在研究具有基于 Web 的用户界面的旧版应用程序。考虑到它的使用年限（某些部分将近 10 年），有很多地方需要更新和重新架构，但我想知道关于用户会话如何工作的一个小问题。

简而言之：

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

我不是安全专家，以前从未见过这种设计。我很想知道你可以从中看到哪些陷阱和风险（如果有的话）。 （我，我有一种不好的感觉，但想要一些更可靠的输入。）

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

Answer 1

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

会话 cookie/令牌是唯一的，它们不会泄露给其他用户。使用 HTTPS 可确保在您的应用程序中无法在线上嗅探这些内容。但是，是否可以猜测会话令牌的值？如果是这样，你就有问题了；现代应用程序依靠安全框架使用良好的 PRNG 生成会话 cookie/令牌。如果您的应用程序不享有类似级别的随机性，则假设会话令牌可以很容易地推断出来，从而导致用户能够欺骗其他用户。

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

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

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

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

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

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

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

Answer 2

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

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

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

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