SESSION / HTTP会话与应用程序制作的会话ID

Question

在基于专有MVC和授权模型的Web应用程序中，我们最近迁移到了Spring MVC。 作为该移动的一部分，我们还在考虑从每个请求传递的本地创建的GUID转移到基于cookie的会话ID。

从表面上看，看起来好像在我们的情况下，这样做会有一个很大的缺点，因为标准的JSESSION / HttpSession似乎是所有安全罪恶的根源：

1. 会话修复（现有代码会话仅在成功登录后创建，因此我们永远不需要使会话无效（）。
2. CSRF - 会话永远不会作为cookie传递，所以这绝不是一个风险（上帝，这是一个有问题的处理，因为没有真正的框架或通用解决方案，因此检查HDIV和CSRFGuard）。
3. 测试可用性 - QA可以轻松拥有多个角色连接到同一服务器的多个用户，而JSESSION则无法实现。
4. 在各种容器（Weblogic，JBOSS和Websphere）中创建和无效的一致HTTPSession
5. 在HTTP到HTTPS之间移动时，JSession处理不一致。

所以，除了“标准”的明显优势之外，还有任何关于我为什么要进入JSESSION路线的线索？

Answer 1

关于你为什么应该或不应该使用jsession，并不是一个明确的答案，但对你的担忧仍然有一些评论：

1. 您的申请不应该依赖会话存在与否。它应该依赖于会话根据您放在其上的某些规则有效这一事实（用户通过身份验证，分配给该用户的角色等）。
2. 只要你注意不使用GET进行明智的行动，CSRF就不是什么大不了的事了，正如你提到Spring MVC一样，用它来实现它很容易。
3. 是的，如果你只依靠一个浏览器。作为旁注，虽然手动测试仍然是某些情况的必要条件，但许多用例可以从自动化中受益，从而减少必须从角色切换到另一个角色的影响。
4. 永远不会遇到问题。但我尽量保持会话内容尽可能小。
5. 这是件好事。它可以防止您在没有注意到的情况下远离安全连接。

现在，无论你选择什么选项，都会有一些缺点。在每个请求中（因此可能在每个GET URL中）具有UUID不允许您的用户轻松使用书签。也不保持他们的会议活着。

Answer 2

经过大量讨论分析和测试后，似乎至少在我的情况下，非RESTfull应用程序，像RIA UI这样的桌面，以及广泛的安全性考虑，JSESSION不是要走的路（主要是CSRF）和更好的选择是基于BODY的内部生成密钥。 但这确实意味着应用程序将被强制处理超时和会话失效。