How to protect my JSESSIONID from document.execCommand(“ClearAuthenticationCache”)?

Question

This might be a duplicate of this question, but the solution proposed isn't viable for us: Protect against 3rd party callers of document.execCommand("ClearAuthenticationCache")? Clears our session cookies

Long story short: IE has a way to clear session cookies using JavaScript - document.execCommand(“ClearAuthenticationCache”). This is used in a variety of web apps including Outlook Web App (and presumably many others). Problem is MS in their infinite wisdom decided that this command should clear session cookies for all open sites (can you tell I'm a little bitter, it took me months to find the source of randomly missing JSESSIONIDs).

We use JSESSIONID as well as another token to make sure the user is authenticated. The JSESSIONID is secure and httpOnly. This works well except when the JSESSIONID is wiped out by a third party. So my question is in two parts:

1. Is there a way I can protect my session cookies from this (let's assume anything involving client side configuration, such as pinning or registry hacks, is a non-option)?

2. If not, is there a way for me to securely recover from this? Since the JSESSIONID is httpOnly, the browser shouldn't be able to read it, but maybe there is something I'm not thinking off.

If relevant: we use Tomcat 7 as our webserver. The app is a fairly complex SaaS app, and security is fairly important.

Thanks all.

Answer 1

I believe either of the following options would work to protect servlet sessions from document.execCommand(“ClearAuthenticationCache”):

You could set the max-age of your JSESSIONID in your web.xml. That way your JSESSIONID cookie would no longer be a session cookie! This would make your web application slightly less secure as the cookie would still survive after the browser is closed.

You could abandon HTTP cookies altogether and configure Tomcat to do session tracking with the SSL session ID. I've never actually configured it myself, but I would guess that this is more secure than using JSESSIONID cookies. However, session replication is not possible in this configuration.