Request Assumes Identity of Another User who Logs in Concurrently Due to Apache CacheIgnoreHeaders
Platform Notice: Data Center - This article applies to Atlassian products on the Data Center platform.
Note that this knowledge base article was created for the Data Center version of the product. Data Center knowledge base articles for non-Data Center-specific features may also work for Server versions of the product, however they have not been tested. Support for Server* products ended on February 15th 2024. If you are running a Server product, you can visit the Atlassian Server end of support announcement to review your migration options.
*Except Fisheye and Crucible
Symptoms
The session spontaneously switches to another user. The JSESSIONID cookie of the victim is set for the "perpetrator" (in complete ignorance as well as innocence), leading to the session-stealing behavior.
Cause
Apache webserver, which proxies the Tomcat server was configured to cache certain fixed-content files to relieve Tomcat of the traffic. The configuration does not take care to use the CacheIgnoreHeaders directive to tell mod_cache not to cache Set-Cookie headers with the responses. When a combination of unusual circumstances coincided for two users - the cached item, with its Set-Cookie header, was returned to another user.
Resolution
If these problems are encountered, you can either:
- try disabling the
mod_cache - or invoke the directive
CacheIgnoreHeaders Set-Cookiein Apache's mod_proxy configuration.
For more details on how to configure mod_cache see also Configuring Apache to Cache Static Content via mod_disk_cache
If the proxy configuration does not match here, it's possible that the behaviour described in JRASERVER-47583 - Integrating with LDAP causes session hijacking when the user unique ID attribute is not unique may be causing the problem. If this is the case please follow the workaround in that bug.