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

Question

This may be a duplicate of this question, but the proposed solution is not practical for us: Protect document.execCommand ("ClearAuthenticationCache") from third-party callers? Clears session cookies .

In short: IE has a way to clear session cookies with JavaScript - document.execCommand("ClearAuthenticationCache") . This is used in various web applications, including Outlook Web App (and, presumably, many others). The problem is that MS, in her infinite wisdom, decided that this command should clear the session cookies for all open sites (can you say that I'm a little bitter, it took me months to find the source of the randomly missing JSESSIONID),

We use JSESSIONID as well as another token to ensure that the user is authenticated. JSESSIONID is safe and httpOnly . This works well unless the JSESSIONID is destroyed by a third party. Therefore, my question consists of two parts:

• Is there a way to protect my session cookies from this (let's say that everything related to client-side configuration, such as pinning or registry, is optional)?

• If not, is there a way for me to safely recover from this? Since JSESSIONID is httpOnly, the browser should not read it, but maybe there is something that I don't think about.

If necessary: ​​we use Tomcat 7 as our web server. The application is a fairly sophisticated SaaS application, and security is pretty important.

Thanks to everyone.

Answer 1

I believe that any of the following options will work to protect servlet sessions from document.execCommand("ClearAuthenticationCache") :

You can set the max-age your JSESSIONID in your web.xml. Thus, your JSESSIONID cookie will no longer be a session cookie! This would make your web application a little less secure, as the cookie will still persist after you close your browser.

You can completely refuse HTTP cookies and configure Tomcat to track the session with an SSL session ID . I never set it up myself, but I would suggest that it is safer than using JSESSIONID cookies. However, session replication is not possible in this configuration.