Tomcat and HttpOnly Session Cookies

Just wanted to let you know that Apache Tomcat can now be configured to use HttpOnly session cookies. I had forgotten about Jim Manico's crusade to get HttpOnly support in Tomcat. It is a shame that it took so long to happen. Microsoft had introduced the concept of HttpOnly cookies primarily as a defense against session hijacking where a cross-site scripting attack is used to steal a session cookie. If a web application sets a cookie with the HttpOnly attribute, web browsers do not allow client-side script to access the cookie. The first browser to support HttpOnly was Internet Explorer 6 SP1 and for a long while IE was the only browser that supported it. That has changed as Firefox and Opera, for example, now support HttpOnly as well.

In Tomcat, enabling HttpOnly for the JSESSIONID is done at the context level, which means it can be controlled for each individual web application. You simply need need to add the following attribute to the <context> element:

useHttpOnly="true"

The default is "false", so you must explicitly add the line above to implement an HttpOnly session cookie. This capability first appeared in Tomcat 6.0.19 (current version = 6.0.20) as well as Tomcat 5.5.28, which is currently the latest version in the 5.5 branch.

OWASP Top Ten Changing for 2010

A new version of the OWASP Top Ten will be arriving in early 2010. At the AppSec DC conference, I attended a session by OWASP board member Dave Wichers that described the proposed changes. First, the emphasis will be on risk, whereas the 2007 version focused on the most prevalent vulnerabilities. The updated list considers not just prevalence, but also the damage level that could result from successful exploitation.

The biggest changes are that Malicious File Execution and Information Leakage/Improper Error Handling are dropping off the list for 2010. In their place, Security Misconfiguration and Unvalidated Redirects/Forwards are being added. Some other items are shifting around. The chart below sums up the changes very nicely.
The release candidate of the new Top Ten is now available for download as a PDF document. OWASP is requesting feedback on anything and everything until December 31, 2009. I've not yet read the document in detail. At first glance, I wonder about the naming conventions. For example, is "Injection" descriptive enough? Is "misconfiguration" a real word? Why is "Insecure Communications" changing to the more cryptic "Insufficient Transport Layer Security"? I guess now is the time to ask!

XSS via Cookie - How Severe?

Take a web application that sets a cookie. Now let's say the application takes the cookie value included in subsequent requests and outputs it into the HTML of the responses. Also assume this occurs with no authentication required and with no output encoding being done. Yes, this application is susceptible to reflected cross-site scripting.

I recently tested such an application. Interestingly, both HP WebInspect and Burp's active scanner reported the XSS vulnerability, but they were at opposite ends of the spectrum in terms of rating its severity. WebInspect rated it "critical" (the most severe rating), while Burp rated it as "information", which implies you don't even need to concern yourself about it.

So why the big disparity in these tools? Is it critically severe, or is it really no big deal? In my view, the answer is somewhere in between. This type of vulnerability is clearly very difficult to exploit. An attacker would somehow have to cause a victim's browser to send a script-injected cookie as part of a request to the vulnerable site. But regardless of the difficulty level, the application should properly encode the cookie value when it is written into the HTML page. Please let me know your opinion on how serious you think this type of vulnerability is.