4

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

从表面上看，在我们的例子中，这样做似乎是一个很大的劣势，因为标准的 JSESSION/HttpSession 似乎是所有安全问题的根源：

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

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

4

2 回答 2

1

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

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

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

于 2011-03-04T12:55:44.047 回答
0

After much discussion analysis and testing, it seems that tleast in my case, a non RESTfull application, with a desktop like RIA UI, and extensive security considration, JSESSION is not the way to go (CSRF mainly) and a better option is a BODY based internally generated key. This does mean though, that the application will be forced to handle timeouts and session invalidation.

于 2011-03-31T19:45:49.007 回答