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

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

简言之：

• 整个UI通过HTTPS提供服务
• 通过将用户名和密码哈希值与保存在数据库中的值进行比较，可以对用户进行身份验证
• 在进行身份验证时，将设置浏览器cookie，其中包含两个值，一个是过期日期，另一个是“loggedin=true”，用于保存用户访问的最后一个顶级和第二个顶级节/模块。注销后，cookie将重置为“loggedin=false”。cookie中没有会话令牌
• 身份验证后加载的第一个页面以及随后的每个页面加载都包含一个JavaScript变量“sessionToken”，它是一个base64编码字符串，包含多个部分，其中一些部分经过加密：

  var sessionToken=“…”

• 每个导航链接都会通过
  元素和JavaScript事件处理程序生成一个HTTP POST请求，并在后台将相关变量与sessionToken一起传递给它，sessionToken在下一个页面加载时会以同样的方式再次设置。如果cookie同时具有“loggedin=true”且过期时间未过，则用户将保持登录状态
• 会话在可配置的时间后过期。过期时间过后，下次单击导航项时将发生过期。我相信这只是比较上次在后端写入会话令牌的时间，但可能使用了cookie——我还没有发现这一点。当会话过期时，cookie中的“loggedin”值被翻转，用户被重定向到登录页面

我不是安全专家，也没有见过这种设计。我很想知道你能从中看到什么陷阱和风险。（我，我有一种不好的感觉，但我想要一些更可靠的输入。）

---

如果这是web某个角落的标准方式，我也想听听。Cookie显然是可以操纵的，因此任何类似于身份验证的“loggedin=true”都会引起一个标志，除非它严格用作一种方法，导致针对sessionid的进一步身份验证检查，等等

注销后，应删除cookie，而不是将其设置为“loggedin=false”

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

---

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

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

会话Cookie/令牌是唯一的，不会泄露给其他用户。使用HTTPS可以确保在您的应用程序中不会在网络上嗅探到这些信息。但是，可以猜测会话令牌的值吗？如果是这样，你就有问题了；现代应用程序依赖于一个安全框架，使用良好的PRNG生成会话cookie/令牌。如果您的应用程序没有类似程度的随机性，那么假设会话令牌可以很容易地推断出来，从而导致用户能够欺骗其他用户

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

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

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

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

PS：还要验证用于密码的哈希算法；用盐是好的。MD5在所有实际用途中都被破坏了

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

---

乍一看，在不使用cookie的情况下使用会话令牌似乎没有任何重大问题，但往往会丢失大多数平台上可用的一些安全特性—cookie标志。secure和HttpOnly cookie标志降低了cookie在线路上被嗅探的风险（当客户端发送到服务器时），并且还确保客户端代码没有访问令牌的权限，该令牌稍后可能会受到XSS攻击的危害。因此，使用会话cookie比使用自定义会话令牌要好（对实现很少或没有进行同行审查）。

谢谢。实际上，由于各种原因，导航设计是一个巨大的难题。我最想知道的是生成JavaScript来设置会话令牌的含义——我想客户端可以以意想不到的方式访问会话令牌。我还在考虑这个问题。非常感谢。密钥管理本身就是一个问题，其含义超出了UI登录会话。我最喜欢的是什么