Internet Explorer expires session when sent from secure to non secure page

[Bridget Carlson]

It just keeps getting better for me as I test my site pages in Internet Explorer. I'm having problems that the other browsers do not present.

Here's the scenario -
1) I open a new IE window.
2) Navigate to a secure page (https) for logging in.
3) If login is successful, user is sent to a non secure (http) page.
* IE pops up the "you are going to a non secure page.."

On the very first attempt to run this sequence, it appears that IE is clearing my session attributes. I say this because when the Java Servlet (validates user submitted data) is then accessed, it sends the user to my 'session expired' page rather than completing the login and forwarding to the 'success' page. Its forwarding to the 'session expired' page, because a session attribute that should be there, isn't any longer.

So its clear that its clearing my session attributes. If it wasn't, the user would've been forwarded to the non secure page successfully. Its also obvious that IE has a problem going from a secure page to one that is not secure.

Here's where it gets even stranger - If I go back to the login page at this point, and try to login again, the process works as it should...and its smooth sailing from there on. I can continue browsing without any problems.

If the user was sent to a secure page after logging in, then things work, right up until I click a link to access a non-secure page...again, it removes the session attributes.

I don't have this problem at all in Firefox and Chrome.

Any ideas as to what I could do to fix this issue? Short of telling my users not to use IE..or telling them to be prepared to have to login at least twice....???

[ramprasad madathil]

On the very first attempt to run this sequence, it appears that IE is clearing my session attributes. I say this because when the Java Servlet (validates user submitted data) is then accessed, it sends the user to my 'session expired' page rather than completing the login and forwarding to the 'success' page. Its forwarding to the 'session expired' page, because a session attribute that should be there, isn't any longer.

The Session object and it's attributes are objects that reside on the server and IE cannot do anything about it

What's probably happening is that the session cookie (that identifies the session on the server and which usually has the name JSESSIONID) is not being sent in the http request from IE. To verify this, you could use a tool like 'Fiddler' with IE to monitor http headers.

Somewhere along the line, in that http request, the absence of a session forces a component (servlet/filter/jsp) to create a new one which obviously wouldnt have the session attribute that identifies the logged in user and hence the login page.

cheers,
ram.

[Bridget Carlson]

ramprasad madathil wrote:What's probably happening is that the session cookie (that identifies the session on the server and which usually has the name JSESSIONID) is not being sent in the http request from IE. To verify this, you could use a tool like 'Fiddler' with IE to monitor http headers.

Somewhere along the line, in that http request, the absence of a session forces a component (servlet/filter/jsp) to create a new one which obviously wouldnt have the session attribute that identifies the logged in user and hence the login page.

Do you know of any way to get around this problem?

Why does it work on the second time I login, in the same IE window? That part I don't understand.

[Bridget Carlson]

The only thing I can come up with, as a workaround, is to have my servlet that validates the login values, check the session, and if the session variable I need has been removed, I will have to recreate it. This may be the only thing I can do for a quick fix, since its IE's problem.

Anyone have a better solution to my problem? I'm open to just about anything.

[Bridget Carlson]

This is not just an IE problem as I had thought.

Also, my idea of working around this problem, isn't going to quite work out too well.

I did some further testing....

What I've noticed, is that when I'm on a secure https page, the jsessionid is NOT present in the url, whereas on the non-secure pages (http), the jsessionid is there.

This would, in part, explain why the secure login page is creating a new session and thus expiring the previous one - thereby forwarding me to the 'session expired' page when I try to login.

Questions
1) Is it possible that I don't have SSL setup correctly?

2) Is there some sort of configuration I have to make in my Tomcat server? Anything having to do with the jsessionid?

Can someone please help me out?

[ramprasad madathil]

What I've noticed, is that when I'm on a secure https page, the jsessionid is NOT present in the url, whereas on the non-secure pages (http), the jsessionid is there.

You had previously mentioned that the scenario works well in other browsers. Is that still true? Or is it not working across all browsers?

Questions
1) Is it possible that I don't have SSL setup correctly?

2) Is there some sort of configuration I have to make in my Tomcat server? Anything having to do with the jsessionid?

It is very difficult to remote debug such issues .
Does your app create secure cookies for http session?
How do you navigate the user to the secure page - is it through a response.sendRedirect() call?
How is the session created - by an explicit call to request.getSession(true) or is it handled by the tomcat container using declarative security in your web.xml?

ram.

[ramprasad madathil]

After some digging around, it looks like the probable cause of this issue is what I had mentioned in the last post - secure cookies.

If the session cookie is created from a secure request (https), it would by default be created as a secure cookie. Secure cookies are not sent along with http requests which would explain the problem you are faced with. Check out this discussion on tomcat mailing list - http://www.mail-archive.com/[email protected]/msg83724.html

One obvious work around is to have a initial http request that creates a session and then redirect to the https page. Another hack would be to manually copy over the jsession id cookie and have it as non-secure (default behavior if you craft a cookie through code). This cookie would then overwrite the secure cookie set in the https exchange. The approach is outlined in this blog - http://www.nuwanbando.com/2010/05/sharing-https-http-sessions-in-tomcat/

cheers,
ram.

[Tim Holloway]

I harp on this a lot, but people who invent their own J2EE security systems also invent their own boatload of trouble. They have to re-design and re-debug an entire security environment, and they almost invariably fail to actually make it secure. In fact, most DIY security systems can't stand a basic 15 minutes of assault. This is why I tend to use the J2EE builtin security system instead of trying to demonstrate how much cleverer I am than people whose full-time job is J2EE security.

HTTPSession objects in J2EE are server-side objects. However, since HTTP is a stateless protocol, the only way to associate a session with a specific user is to pass a "handle" back and forth with each HTTP request/response. This can be done in one of 2 ways: via URL rewriting (jsessionid) or via cookies. Technically, you could do both (and some servers may), but obviously one one of them has to be definitive in case the 2 don't agree for any reason.

It's always good practice to support both types of session handle propagation. You never can tell when a user may have cookies disabled for some reason, but at the same time, URL rewrites have liabilities as well - they find it easy to lose the sessionID, the sessionID is out in public where people will be more tempted to tinker with it, and, of course, bookmarking a sessionID is useless once the session expires.

IE whines and cries both when you transition between SSL/non-SSL and when you mix SSL and non-SSL on the same page. And to be truthful, they have a point. It's really much better once secure mode has been entered to do EVERYTHING in secure mode. Bad Guys can find exploits almost anywhere.

There are a number of arguments against SSL, but most of them are specious. The most offensive one is the overhead argument. Yes, there's a small extra cost involved in encryption and decryption. However there's a LARGE extra cost involved in security failures. And if you're already running 100%, you're only 1% away from horrible systems failures. There is such a thing as "too much efficiency".

A more justifiable argument has to do with the fact that some platforms will reduce or eliminate browser caching when SSL is in use. That can impact performance a lot more than the overhead of encryption, but there's a reason why caching is discouraged when secure data is in play. That, however, can be allowed for. I spent last week doing that, in fact.