JSESSION/HTTPSession与应用程序生成的会话ID有何区别？

Question

在一个基于专有MVC和授权模型的Web应用程序中，我们最近迁移到了Spring MVC。作为这一举措的一部分，我们还考虑放弃每个请求中传递的本地创建的GUID，并改为基于cookie的Session ID。

表面上看，对我们来说，这样做似乎会带来很大的劣势，因为标准的JSESSION/HttpSession似乎是所有安全问题的根源：

1. 会话固定攻击（在现有代码中，只有在成功登录后才创建会话，因此我们永远不需要使会话失效）。 2. CSRF - Session从未作为cookie传递，因此这从未成为风险（而且，它是一个难以处理的问题，因为没有真正的框架或通用解决方案，已检查HDIV和CSRFGuard）。 3. 测试可用性- QA可以轻松地拥有多个用户与多个角色连接到同一服务器，而使用JSESSION则不可能。 4. 在各种容器（Weblogic、JBOSS和Websphere）中创建和使HTTPSession失效的不一致性。 5. 在HTTP到HTTPS之间移动时，JSession处理的不一致性。

那么，除了“成为标准”的明显优势外，有什么线索可以让我选择JSESSION路线吗？

- JAR.JAR.beans

---

我很好奇，您认为HDIV和CSRFGuard在CSRF保护方面有哪些不足之处？ - laz

HDIV的支持并不足够。它看起来是一个有趣的包，我希望我能使用它。但是，根据文档实施时遇到了问题，需要帮助时却没有得到回应。您可以查看论坛以了解动态。 - JAR.JAR.beans

CSRFGuard看起来是一个不错的解决方案，但在CSRF空间中它实在是太麻烦了。我已经拥有了我的专有会话ID，我用JSESSION替换它以查看是否存在CSRF问题，所以现在我可以添加一个新的包来生成...一个专有会话ID...我最好（也就是我所做的）将JSESSION从我的解决方案中排除掉，因为它在某些RIA解决方案中根本无法使用，就像在我的情况下一样。 - JAR.JAR.beans

Answer 1

关于是否应该使用jsession，这并不是一个明确的答案，但仍然有一些关于您担忧的评论：

1. 您的应用程序不应该依赖于会话存在与否。它应该依赖于会话是否根据您对其设置的某些规则有效（用户已验证，为此用户分配了角色等）
2. 只要注意不要在敏感操作中使用GET，CSRF就不是真正的大问题，正如您提到的Spring MVC，使用它非常容易实现。
3. 如果您只依赖于一个浏览器，那么是真的。顺便说一句，虽然手动测试对于某些情况仍然必须进行，但许多用例可以从自动化中受益，从而减少了从一个角色切换到另一个角色的影响。
4. 我从未遇到过这样的问题。但我尽量使会话内容尽可能小。
5. 这是一件好事。它可以防止您在没有注意到的情况下离开安全连接。

无论您选择哪个选项，都会存在一些缺点。在每个请求中（因此可能在每个GET URL中）使用UUID不允许用户轻松使用书签。也无法保持他们的会话活动。

- gizmo

---

关于您的评论，我有几点想说（并感谢您的意见）：2）CSRF比人们所认为的更加危险，并且可以在POST中轻松使用（以及Spring MVC）。4）例如WebSphere不会创建会话，除非调用HttpSession.getSession，这与WebLogic的行为不同。但总体而言，我没有听到任何避免使用Jsession的“大不了”。 - JAR.JAR.beans

Answer 2

经过讨论、分析和测试，似乎在我的情况下，一个非RESTful应用程序，具有类似桌面的RIA UI和广泛的安全考虑，JSESSION不是最好的选择（主要是CSRF），更好的选择是基于BODY内部生成的密钥。这意味着应用程序将被迫处理超时和会话失效。

- JAR.JAR.beans