2

我继承了一个非常古老的 JSP 应用程序（JDK 1.3.1_15）并试图填补一个会话固定漏洞。

我在使用身份验证后成功地使当前会话无效，HttpSession.invalidate()但是在创建新会话时，旧会话 ID 被重新使用。

<%
// login.jsp
if (authenticated) {
    request.getSession().invalidate();

    // create new session and store data
    HttpSession session = request.getSession();
    session.putValue(...);
    // etc

    response.sendRedirect("logged-in.jsp");
    return;
}
%>

我可以在我的 HTTP 监视器中看到新的会话分配，它只是再次使用相同的数字。

-- Initial request response --
HTTP/1.1 200 OK
Set-Cookie: JSESSIONID=6a303082951311647336934;path=/

-- login.jsp request response --
HTTP/1.1 302 Moved Temporarily
Location: http://example.com/logged-in.jsp
Set-Cookie: JSESSIONID=6a303082951311647336934;path=/

在我使用session.invalidate()第二个Set-Cookie响应标头之前根本不存在。

有人对如何生成新的会话 ID 有任何建议吗？我对 JRUN4 不是很熟悉，但是浏览配置文档并没有发现任何问题。

4

2 回答 2

3

要解决此问题，您可以使用第二个非持久性 cookie 作为您可以控制其值的会话 id。这个想法是生成一个唯一的 id 并将其存储在 cookie 和会话中。使用此 cookie 实现与您尝试通过使用 invalidate 对会话执行相同的逻辑。具体来说，在身份验证成功之前，不要发出将被未来请求接受的实际标识符。然后创建一个 Servlet 过滤器，它检查每个请求并将这个新 cookie 的值与会话中存储的值相匹配。如果它们不匹配，就会发生一些邪恶的事情。我知道这比仅仅依靠session.invalidate()颁发一个新的id要麻烦一些。但是考虑到您的限制和 JRun 的行为，这将提供足够的保护来防止会话固定。

于 2011-07-31T05:16:27.617 回答
1

从Java Servlet 3.0 规范的第 7.3 节可以看出：

HttpSession 对象的范围必须在应用程序（或 servlet 上下文）级别。底层机制，例如用于建立会话的 cookie，对于不同的上下文可以是相同的，但引用的对象，包括该对象中的属性，决不能由容器在上下文之间共享。

这是一个非常糟糕的想法，但我想知道 JSESSIONID cookie 是否只是被简单地重复使用并且实际的会话上下文被破坏了。你还能访问无效会话的状态（即属性）吗？

于 2011-07-29T01:48:54.890 回答