In the wake of Tomcat 7 being announced as a stable release, Mark Thomas, SpringSource Employee and member of the Apache Security Committee, shares some of the insight behind the new cross-site script (XSS) protection feature introduced into Tomcat 7, 6 and 5 through this latest release effort.
In describing the problem, Mark explains:
Cross-site scripting (XSS) is the leading form of security vulnerabilities for web applications today. This vulnerability is found when attackers are able to inject client-side scripting into web pages by tricking the browser to trust scripts run from malicious hosts. These scripts usually access user and session information stored in cookies, and allow the hackers to forge trusted user behavior. The result can allow hijackers to control your user account, change your account settings, or redirect web traffic to malicious or false advertising sites. Recently, there has been an increase in high-profile cross-site scripting attacks on sites like Twitter and IBM's DeveloperWorks, which illustrate how common these vulnerabilities exist on web sites both large and small.
A single new element, with a flag set to true will reduce the risk of these security vulnerabilities by preventing the browser from allowing scripts to access information stored in cookies. Thomas explains further how it works:
In Tomcat, the use of the httpOnly flag on a cookie is controlled by a new Context element called useHttpOnly. When this is enabled, it prevents client-side scripts from accessing Session IDs in cookies. By default, the cross-site script protection is turned on in Tomcat 7 (useHttpOnly is set to true), and while you can turn it on Tomcat 5.x and Tomcat 6.x by default is turned off, mainly due to backwards compatibility concerns.
Thomas stresses this is not a universal fix. One case where problems using this solution may exist is for web applications that use applets. If the applet requires information about the user session to complete its functions, marking the context element useHttpOnly to true will prevent that applet from accessing the session information and break the application.