JSP's Expression Language does not XML-escape it's content by default. While <c:out> and ${fn:escapeXml(string)} can be used, I think it's a nice option to allow turning on escaping by default - in Tomcat's web.xml. This is similar to the "trimSpaces" option that Tomcat added before it was part of the JSP spec. Related: http://raibledesigns.com/rd/entry/java_web_frameworks_and_xss I'll attach a patch to make this possible.
Created attachment 20891 [details] Patch to add the ability to escape the rendered output of JSP's EL by default
*** Bug 45652 has been marked as a duplicate of this bug. ***
Any chance this bug receives some attention? Any application on Tomcat is susceptible of XSS attacks, and it should be easy to fix. Keeping the current behavior as default is reasonable, but please provide some flag to switch. Right now I have to keep my own separate patch jar, and merge into Tomcat.
If you don't want to patch Tomcat, here is a custom ELResolver that XML-escapes EL values. You just have to add a servlet context listener to web.xml to configure it in your web application. http://pukkaone.github.com/2011/01/03/jsp-cross-site-scripting-elresolver.html
It is not as simple as this patch suggests. The necessary escaping to prevent XSS varies by context [1]. The necessary context information is not available to Tomcat so Tomcat is unable to ensure that the correct escaping is applied. There are several possible approaches to solve this issue but none of them can be currently applied to Tomcat: 1. Provide methods to do this in the framework being used and expect/require developers to set the context appropriately. 2. Use a framework that is sufficiently strict that the context is always known and the necessary escaping can be applied automatically. 3. Modify the EL spec to allow the context to be supplied. At this point the escaping may as well be automatically applied as well. Option 3 could be implemented in Tomcat if the EL spec was changed. That would be Tomcat 8 at the earliest. [1] http://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_Cheat_Sheet
I disagree. 99% of the XSS injection cases are described in the mentioned link as RULE #1: escape HTML. Even worse, 99% of these cases could be implemented by simply escaping < or any UTF-8 equivalent (some of the escaped characters proposed in the link, like > do not have any known exploits in modern browsers). We are talking about any use of ${user.name}, ${post.contents}, ${comment}. These are by far the most common use case. Other cases: * Cases where sanitizing is NOT desired: you can always fallback to <c:out> * A command-line flag can be used to disable sanitizing altogether. * Cases where extra processing is desired (like attribute escaping): for these cases the programmer can invoke extra functions. I have to say, I have not found a single case where attribute escaping (or javascript for that matter) was required. I don't mind sanitizing these by hand, but this patch would make 99% of Tomcat applications safer by default.