Accidental Session Hijacking CFMX7

[sws]

Hi all,

I'm stumped and need some help. I have a MX7 application using J2EE session vars. A couple thousand members log into the application each day. Every few months over the last year and a half or so, we run into a problem where one user will suddenly be logged into another user's account. This has always been accidental. We've haven't experienced the problem in probably 6 months and all of the sudden we got 5 separate calls about it yesterday.

We've been investigating this for a while. From what we can tell, the sessions get swapped between members that happen to be accessing the site from the same network (we save IP addresses on the transactions). Sometimes the person recognizes the other user as a coworker or a neighbor in the same building. These problems usually occur from networks that would typically have proxy servers installed.

My guess is that the proxy servers are incorrectly caching cookies (we never pass the session token in the URL). From what I understand about proxy servers, we could correct this problem by using SSL (proxies can't or won't cache encrypted pages). We tried this and it seemed to be working, however, we had to abandon the solution because it was causing problems for users accessing the site from cell phones and PDAs (many of the pages on the site are very large and when encrypted cause huge delays for these users).

Cookies are set in the http response header. If my guess is right and the proxy servers are caching the cookies, my next plan of action is to append a large random number to every URL query string in the application. My thought is that even if the proxy caches the page, every request will have a different URL so the client will never be given a cached page.

What do you think? Anyone experience a similar problem? Am I on the right track? Is there a better way to solve this problem?

Thanks for your input.
--Sam

(Coincidently, our ISP was having problems yesterday and access to our site was up and down a few times. I can't reconcile this with the hijacked sessions but I figure I should mention it anyway.)

[Sarge]

Sam,

Have you also tried HTTP cache control headers? For example, before you append the UUID to the URL, try setting Pragma, cache-control, and expires headers. You should be able to find the right combination of headers and values to prevent Proxy caching. Read more at http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html.

HTH,

[sws]

Sarge,

I have content-expiration enabled in IIS 6 and have it set to expire pages immediately so no, I have not set these values using cfheader or meta tags. (I thought I had read it was a better practice to set the HTTP headers at the webserver.) But, what I decided to do after reading your post, was look at the actual headers that were being returned. I used cfhttp method="head" and dumped the results. I was very surprised to find that requests to CFM files do NOT contain the HTTP cache control headers!!! The requests to other files (html, css, js, gif) did contain the proper cache control headers. Check it out...

<cfhttp url=" http://localhost/test.cfm" method="HEAD"> returned the following header:
HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Set-Cookie: CFID=430878;expires=Sun, 14-Sep-2036 18:56:11 GMT;path=/
Set-Cookie: CFTOKEN=20145908;expires=Sun, 14-Sep-2036 18:56:11 GMT;path=/
Set-Cookie: JSESSIONID=50306022bec03546587e;path=/
Connection: close
Date: Fri, 22 Sep 2006 18:56:11 GMT
Server: Microsoft-IIS/6.0

<cfhttp url=" http://localhost/test.html" method="HEAD"> returned the following header:
HTTP/1.1 200 OK
Date: Fri, 22 Sep 2006 18:56:11 GMT
Accept-Ranges: bytes
Server: Microsoft-IIS/6.0
Content-Length: 152
Cache-Control: no-cache
ETag: "cefbb1677dec61:4c1"
Last-Modified: Fri, 22 Sep 2006 18:44:09 GMT
Content-Location: http://localhost/test.html
Content-Type: text/html

I can't believe it. Why doesn't IIS include the HTTP cache control headers for cfm files?

David -
1) Initially I tried appending the session token to the URL. I'm pretty sure it solved our problem with the proxies. We abandoned this solution because it created a new problem. Members would email each other links to a page within the application. If the email recipient clicked the link before the session expired on the server, they would suddenly be logged in as the user who sent the email.

2) I'm referring to session cookies. We have J2EE session variables enabled. CFID,CFTOKEN cookies are still set in the header (see first header above) but ColdFusion uses the JSESSIONID cookie for session management. (Actually, I'm not sure why the cfid,cftoken cookies are created when J2EE session cookies are enabled. Client management maybe?)

[sws]

>Why doesn't IIS include the HTTP cache control headers for cfm files?
Ah, I'm a dummy. It makes sense after I thought about it a minute. IIS content expiration must only be for static files. I tested an .asp file and got different headers. No Etag or Last-modified for the .asp file but interestingly .asp automatically sends Cache-Control: private. I just assumed when you set content expiration on an IIS directory it would add the headers to all files in the directory.

Edit:
I've since added the following code to my Application.cfm files:

<cfheader name="Cache-Control" value="private">
<cfheader name="Cache-Control" value="no-cache">
<cfheader name="Expires" value="#GetHttpTimeString(DateAdd('d', -1, Now()))#">
<cfheader name="Pragma" value="no-cache">

[davidmedifit]

Sam,
Just a question or two:

1) Is there a reason why you don't pass the session token in the URL? If, at no other time, what about including it in the initial login page (I am speculating that after authentication you cflocate your user to a particular page?)

2) When you say "Cookies" - do you mean session cookies, or physical cookies on the users machine?

Cheers,

David