Common Vulnerabilities and Exposures assigned an identifier CVE-2010-4312 to the following vulnerability: Name: CVE-2010-4312 URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-4312 Assigned: 20101126 Reference: BUGTRAQ:20101122 [SECURITY] CVE-2010-4172: Apache Tomcat Manager application XSS vulnerability Reference: URL: http://www.securityfocus.com/archive/1/archive/1/514866/100/0/threaded The default configuration of Apache Tomcat 6.x does not include the HTTPOnly flag in a Set-Cookie header, which makes it easier for remote attackers to hijack a session via script access to a cookie.
It does not look as though upstream is making this option the default in Tomcat6 as it did in Tomcat7. Should we make this a default in our Tomcat6? I'm not sure if that would cause some unexpected changes in web applications or not.
HttpOnly is supported in tomcat6.0.19+. A patch making the default true was submitted in 2008 but it wasn't applied afaict. This is easy to make the default by adding: <Manager useHttpOnly="true" /> to the default context.xml or if a more narrow approach is needed it can be added to any web-application context. As of 2009 not all browsers treated it the same and it apparently doesn't prohibit all attempts. For some reason, an attacker could still read the session cookie in a response to an XmlHttpRequest on some browsers. However, in most browsers it does prevent writes to the session cookie by a client script. From what I could find, Opera, Internet Explorer, Chrome, and Safari may not prevent writes under any cirumstances.(That may have changed over the last year). Setting the default to true in most cases will tighten it up, but apparently does not close it completely.
In light of the above, is it even worth making the change? Or would this break some expected behaviour in Tomcat6 that could have adverse affects on client applications? If it _doesn't_ cause any adverse affects, and despite it not fixing it completely (seems like it's more dependant on the browser), then we may want to include that change in future tomcat6 updates. If it does cause adverse affects, or can break the assumptions of client applications, then it might be wiser to just note the above as a mitigation in a public statement.
The useHttpOnly flag won't completely protect the client. The implementation is unique for each browser, and therein lies the hole. For applications that can, useHttpOnly will tighten client-side cookie access prohibitions against XSS hacks, but only as well as the client browser implements it. This might be an old approach, and browsers may have tightened up the implementation, however it's not universally canonical as far as i can tell. Maybe someone who better knows the details re: browser implementations of useHttpOnly, can add their perspective. I suggest we add text to the technical notes herewith that includes: * what useHttpOnly is supposed to do: prohibit client script access to cookies when correctly implemented and set in a context xml. It tells the browser that this particular cookie should only be accessed by the server. An attempt to access the cookie from a client-side script is (supposedly) forbidden. * why 'true' should not be the default: based on applications already touching cookies in a client script. Breaking a client script by making this the default would cause greater inconvenience, and the 'it worked before' complaint will be very popular in this case. * If concerned about the risk of this type of XSS hack, how/where to set useHttpOnly in a context.xml. It's a set-it-and-forget-it configuration point.
For technical notes, are you referring to notes in the Tomcat rpms and/or JBoss products using it (JBEWS)? I agree with you, there isn't a significant enough protection here when you end up relying on browsers to properly implement it to warrant this fix, especially in light of the expectations of what Tomcat has worked in the past.
David, Marc, did upstream change the default for useHttpOnly for all sessions created by any webapp running on Tomcat in response to this, or was the default only changed for the Manager webapp? Patch listed in the bugtraq post only contains Manager webapp changes. Can you link related upstream SVN commits if you have them around?
The global change was made in tomcat7, where the codified default is true. Tomcat6.0.29 still maintains the default of false, both in code and configuration. As to using: <Manager useHttpOnly="true" /> The Manager in the above case, is the session manager for this context and is a nested element. Apparently, in the distant past the attribute was on the Context's session manager. There are still numerous examples on the web. However, it's totally wrong; the perils of copy/paste. useHttpOnly is an attribute of the Context container. The config should be: <Context useHttpOnly="true"> </Context> This can be any context definition, per webapp, or all webapps of a virtual host, or all webapps of a server depending on which Context XML is configured.
Statement: This issue is only a defense-in-depth measure, and we currently have no plans to fix this flaw in Red Hat Enterprise Linux 6. The use of the useHttpOnly setting in Tomcat only prohibits client scripts from accessing cookies when it is correctly implemented in the user's web browser. The use of httpOnly does not guarantee XSS protection; it is only a defense-in-depth measure. Additionally, implementing this as a default setting could have negative impact on existing expected behavior in client scripts. As a result, the Red Hat Security Response Team has determined that this issue is not a security flaw, but a proactive hardening measure and the risk associated with implementing it by default and possibly breaking expected behaviour is greater than any benefits it provides. Users who wish to take advantage of this hardening measure can enable useHttpOnly by adding '<Context useHttpOnly="true">' to the default context.xml or a specific web-application context.