6

I want to build a stateless web application using Java Servlets. Because it's stateless, there is no HttpSession. There is a session in the browser, but each request might be handled by a different node in the cluster. The session identifier stored in the browser is generated and encrypted by the server, so it's very hard for someone to craft a valid fake session ID and bypass login.

Recently I found a vulnerability in this architecture: if a malicious (infected) browser sends the session identifier to a bandit, the session can be easily hijacked. I can't regenerate session identifier at each request because there is no session at the server to track the expected request sequence, and that would also complicate handling of asynchronous requests.

My solution so far is to get some HTTPS session identifier and include it on the encrypted session ID that is stored in the browser. Can a standard servlet get such information from HTTPS connection?

Another option would be using HttpSession just for getId(), but that would work only if such ID is tied to HTTPS session, which I couldn't find in servlet specification.

Other suggestions are welcome.

fernacolo
  • 7,012
  • 5
  • 40
  • 61
  • 1
    Validating the ssl session will improve your security, but if the browser is infected with malicious software then you cannot trust that browser for anything. The ssl implementation may also be compromised, the browser may be controlled by a remote agent etc. However, this solution may protect against a specific attack where only the cookies in the browser is compromised. – sstendal Jun 07 '11 at 19:24
  • Validating the SSL session ID doesn't really improve the security. I'm not sure where this myth comes from. It can certainly cause problems for legitimate users, though. – Bruno Jun 10 '11 at 14:29

1 Answers1

8

The servlet container populates the SSL session ID in a HttpServletRequest attribute, to be used by downstream components. The attribute name happens to be javax.servlet.request.ssl_session_id. To my knowledge, this is available in all containers implementing the Servlet Specification 3.0. Prior to Servlet Spec 3.0, this was available in limited containers - Tomcat and Jetty, if I'm not mistaken.

Be forewarned though, that the SSL session ID is considered more secure than the container generated HTTP session cookie value. Leaking the SSL session ID would render even your HTTPS connections insecure.

Vineet Reynolds
  • 76,006
  • 17
  • 150
  • 174
  • 1
    The SSL session ID has absolutely nothing to do with what HTTP "sessions" are used for. A different SSL session ID is no indication that it comes from someone else, it's just the mechanism to keep the SSL/TLS session going (that is, the connection under the application). In contrast, HTTP sessions via cookies are used to keep track of a "conversation" in what's inherently a request-response protocol (HTTP). SSL session IDs should not be used for authentication. Using them doesn't "improve" security, it just limits the "session" to the lifetime of the SSL connection (usually quite short). – Bruno Jun 10 '11 at 14:26
  • 1
    @Bruno, certain application servers do not use HTTP Cookies for tracking state when SSL/TLS is used, instead using the SSL session id. I remember OC4J used to do this, and there were configuration flags available in case anyone wanted to send the session ID using the JSESSIONID cookie. You are right in that the SSL session id is not as long lived as a normal HTTP session cookie value. I don't remember the details of how the server mapped the SSL session ID to a server-side session object, but it is certainly possible. – Vineet Reynolds Jun 10 '11 at 14:33
  • 1
    indeed, I'm not saying it's not possible, I'm saying it's not the right thing to do, because it will cause more problems. Cookies sit on top of HTTP and are used to provide a "conversation" layer on top of the HTTP (otherwise stateless). SSL session ID sit under HTTP. If your browser opens multiple connections, to fetch a page and its images in parallel for example, it may legitimately end up with multiple SSL connections with different SSL session IDs. Assuming that the SSL session will be the same relies on having a rather stable connection (can a problem in mobile environments). – Bruno Jun 10 '11 at 14:41
  • 2
    The benefits of SSL session ID over cookies don't really exist. The cookie is at least protected within the encrypted SSL/TLS connection. The SSL session ID is visible in clear in the handshake. – Bruno Jun 10 '11 at 14:44
  • 1
    @Bruno, I don't disagree at all with your point. The OP perhaps knows more about the problem what he's attempting to solve. We can only explain why certain things are bad idea. I'm afraid I should have explained this earlier (in my post). – Vineet Reynolds Jun 10 '11 at 14:45