Application Server Sessions

WebCenter Interaction 10gR3 included these lines in the release notes:

Security and SSO
• Session fixation vulnerability. (Issue #7824904)

But what does that mean? First, let’s take a look at how sessions work on the World Wide Interwebs. By their very nature, web browsers are “stateless”. This means the CLIENT (web browser) makes a request to the SERVER, gets its information (a web page or image, for example), and closes that connection. The next time it makes the request, the server has no context from the previous request. To get around this, Netscape is credited with inventing the session cookie, which basically works like this:

  1. Web browser makes request to server the first time.
  2. Server realizes no “session” exists, so it creates a “blob of memory” to reserve for that user. It then creates a “key” that it sends to the browser in the form of a cookie in its response.
  3. The next time the browser makes a request, it sends that cookie. The server reads it and maps the cookie to the “blob of memory” that can contain anything, such as the login information of the user, or that user’s shopping cart.
  4. After a period of time (usually 15 minutes), the server realizes it hasn’t heard from the client and clears that memory to conserve resources.

Generally that “key” that we mentioned above is known as the “session ID”, and it’s usually passed in a cookie. But because not all browsers support(ed) cookies, a workaround was to allow the cookie to be passed on the query string. The problem is, if I know that session ID, I don’t even have to log into the web site you’re accessing – I can just send your cookie to that web site, and it will map my request to that “blob of memory” on the server that belongs to you – complete with your shopping cart or access to whatever private portal resources you had access to.

This is a pretty vague oversimplification, and if you’re interested, Wikipedia has decent articles on sessions and session fixation. WCI 10gR3 took additional measures to counteract the problem. Because it’s not open-source, it’s not easy to determine exactly what their solution was, but it involves clearing a session key when the user navigates away from the portal.

The problem is: what if clearing the session isn’t expected behavior? I ran into this exact scenario with a client using AquaLogic User Interaction (ALUI) trying to upgrade to WebCenter Interaction 10gR3. They had a custom SSO solution that redirected the browser to a login page at another domain. The server would redirect the browser to the new URL and the user would login there. After login, the browser would redirect back, but the original session had been deleted.

Bottom line: for most Plumtree installations, the 10gR3 upgrade is more secure and feature-rich. But use caution when applying this patch when you’ve got a custom SSO solution in-place, and test well before go-live!

Tags: ,

Leave a Reply