Bug 43497 - Add ability to escape rendered output of JSP expressions
Summary: Add ability to escape rendered output of JSP expressions
Status: RESOLVED WONTFIX
Alias: None
Product: Tomcat 6
Classification: Unclassified
Component: Jasper (show other bugs)
Version: 6.0.14
Hardware: Other other
: P3 enhancement with 2 votes (vote)
Target Milestone: default
Assignee: Tomcat Developers Mailing List
URL:
Keywords:
: 45652 (view as bug list)
Depends on:
Blocks:
 
Reported: 2007-09-26 19:03 UTC by Matt Raible
Modified: 2011-03-03 07:46 UTC (History)
3 users (show)



Attachments
Patch to add the ability to escape the rendered output of JSP's EL by default (11.30 KB, patch)
2007-09-26 19:04 UTC, Matt Raible
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Matt Raible 2007-09-26 19:03:43 UTC
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.
Comment 1 Matt Raible 2007-09-26 19:04:34 UTC
Created attachment 20891 [details]
Patch to add the ability to escape the rendered output of JSP's EL by default
Comment 2 Mark Thomas 2008-08-31 10:34:16 UTC
*** Bug 45652 has been marked as a duplicate of this bug. ***
Comment 3 Nacho Coloma 2010-10-20 10:48:11 UTC
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.
Comment 4 Chin Huang 2011-02-27 13:49:50 UTC
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
Comment 5 Mark Thomas 2011-03-03 07:14:32 UTC
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
Comment 6 Nacho Coloma 2011-03-03 07:46:15 UTC
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 &lt; or any UTF-8 equivalent (some of the escaped characters proposed in the link, like &gt; 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 &lt;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.