JSF 2.0; escape="false" alternative to prevent XSS?

3
votes

In my jsf webapplication i'm using a messages.properties to output some text. This text could have html line breaks so format the outputtext.

That all works fine, if i set the escape="false" attribute to the outputtext.

The problem is, this attribute with value "false" doesn't prevent vor XSS (cross site scripting) so i remove this attribute and use default-value "true".

So, i dont want to split all text lines to seperate properties in my messages.properties like in this example:

mytext = This is my text<br />with line break and user value {0}...

after:

mytext1 = This is my text
mytext2 = with line break and user value {0}...

is there any way, other than escape="false" but that prevent from xss?

thanks!

2
javajsfxss
You only have to care about XSS when displaying a user content, like comments. For your own text (from properties) just do not place malicious code in there :) – DRCB
Okay, but if there is any user content in there? I updated my question :-) – Tobi
I suppose these are only read-only components so how could anyone XSS them? I do not think that output text cares about values sent by the client. If I am wrong you can always extends the JSF component u r interested in and prevent XSS. If u r using Tomcat 7.0 it provides XSS prevention out of the box – Timmo
What about validating user values? e.g. not allowing user to choose his name as <script type="text/javascript" ..... – andbi
Osw you said it your self[validate]..."Create a validator". If you want a more centralized approach create a filter to sanitize the HTTP request parameter values – Timmo

2 Answers

4
votes

It should be possible to just escape the user supplied parameter using the standard jstl functions in the http://java.sun.com/jsp/jstl/functions namespace:

<h:outputFormat value="#{bundle.myMessage}" escape="false">
    <f:param value="#{fn:escapeXml(param)}"/>
</h:outputFormat>
2
votes

XSS can't happen if you're outputting some HTML from a safe source which is not input or editable by the user. You can safely use escape="false" in this case.