8

我希望几个相关 Web 应用程序的客户端保持自己的身份验证状态。这提高了可伸缩性，因为不需要集群节点之间的会话复制。它使 Java Servlet 和 PHP 等不同服务器技术的集成变得更加容易。

我的计划如下：

  1. 在客户端验证后，使用用户名和会话到期时间设置签名和加密的 cookie。
  2. 当客户端发送请求时，服务器会解密并验证 cookie，并根据 cookie 值授予或拒绝访问。
  3. 会话过期将通过重置 cookie 进行更新。

所有想要使用会话的服务器只需要知道 cookie 机制和解密密钥。另请参阅：客户端层中的会话状态

这种方法可以吗？是否可以将其集成到 servlet 容器/应用程序服务器中，以便对应用程序透明？例如，servlet 应该能够使用 HttpServletRequest#getRemoteUser()。这可能吗？或者我需要像 Spring Security 这样的容器级别以上的东西吗？是否有任何现有的用于客户端会话管理的库？

4

6 回答 6

8

不是一个好主意。将会话到期和用户名等重要数据完全存储在客户端太危险 IMO，无论是否加密。即使这个概念本身在技术上是安全的（我不能深入回答这个问题，我不是加密专家），只要获取您的加密密钥，就可以在不损害您的服务器的情况下促进入侵。

掌握密钥的人可以随意生成会话 cookie，在任意时间模拟任何用户，这是经典会话概念旨在防止的。

对于这个问题，有更好的和可扩展的解决方案。例如，为什么不设置一个所有相关服务器和服务都可以轮询的中央会话验证实例？在网上四处看看，我 100% 确信有现成的解决方案可以满足您的需求。

于 2010-01-25T10:29:03.517 回答
7

我不同意海报说这种方法不安全。它的变体被用于许多备受推崇的框架中，例如 Rails 和 Play!，这正是您概述的原因，并且在正确实施时非常安全。

于 2015-07-09T14:10:12.290 回答
3

这提高了可伸缩性，因为不需要集群节点之间的会话复制。

首先，使用 HTTP Session 并不会真正阻止您进行扩展，即使在使用 HTTP Session 状态复制时也是如此（顺便说一下，有些机制比其他机制更智能，例如 WebLogic 的内存复制并没有很大的开销）。第二，你真的需要吗？大多数应用程序（大多数）不需要会话复制。第三，我的理解是否正确：您打算根本不使用 HTTP Session 吗？

(...) 在客户端认证后使用用户名和会话到期时间设置一个签名和加密的 cookie。

不要这样做！不要将服务器使用的用户名和其他敏感数据存储在 cookie 中，这是一个非常糟糕的主意！您实际上需要承认，有人弄清楚您的系统如何工作并破坏它只是时间问题（特别是如果您的 cookie 是婴儿床攻击的候选者）。或者，真的，您应该将数据存储在服务器端的 Session 中，并且只在 cookie 中存储一个 ID，就像事情实际上正在运行一样。这更安全。

这种方法可以吗？

不。而且您不需要它来进行可互操作的单点登录（如果这是您要构建的）。只需使用像CAS Jasig这样的集中式身份验证解决方案，它具有各种技术的库。

于 2010-01-25T11:31:07.520 回答
1

这实际上并不是 Sessions 的实现方式。cookie 本身不需要携带会话本身的任何数据，它只是对它的引用。

Cookie 保存的通常是一个Session ID，然后链接到服务器上的数据。

如果您没有可供其他服务器访问的中央数据会话服务器，我建议您购买一个 :)。

于 2010-01-25T10:32:04.527 回答
1

您可以通过使用状态服务器来避免集群环境中的数据重复——该服务器为集群中的所有节点所熟知并为所有用户维护会话数据。每次用户执行请求时，它都会向应用服务器发送一个带有会话 id 的 cookie；这个应该从状态服务器检索会话。这对于 asp.net 开发是可能的，但我不确定 Java 支持这种方法有多容易。

于 2010-01-25T10:56:17.013 回答
0

正如Pekka所说，这不是一个好主意。可以使用敏感会话数据拦截您的 cookie。即使使用 SSL，通过使用 fiddler2 也可以解密流量

于 2010-01-25T16:06:57.187 回答