How to decode text when using Primefaces inputText widget?

1
votes

I am trying to add XSS prevention capabilities to my JSF/primefaces system. From reference http://www.ibm.com/developerworks/library/se-prevent/, the way I understand how it should be done is:

  1. Data is saved as is (i.e. decoded) in backend. For instance, "alert(/xss/)"
  2. When displayed as an output, web server (in jsf case, managed beans) will encode the characters. For instance, "<script>alert(/xss!/)</script>"
  3. Browser will download encoded script and convert it back to decoded way. For instance, "alert(/xss/)". To achieve this in JSF, I would need to set outputText attribute escape="false", otherwise it will escape the characters as that is the default behavior.

Apart from the bother of having to explicitly set escape="false" in all my widgets, this solution seems to work. However, the problem comes when instead of having outputText widgets reading from my beans, I have inputText, which will always keep the encoded string coming from the managed bean, and never decodes it back.

Any ideas how I can handle this?

1
jsfprimefacesencodingxss

1 Answers

2
votes

You seem to have a major misunderstanding. That IBM article is clearly targeted at "plain vanilla" JSP applications which indeed don't have any form of automatic XSS prevention (even though you'd in JSP better just use JSTL <c:out> or fn:escapeXml() for this instead of all that clumsiness the article is writing about). JSF, however, has already builtin automatic XSS prevention, particularly when used with Facelets as view technology instead of its predecesor JSP.

You're in first place not supposed to manually decode it in backend. Stopping with step #1 will solve everything; you do not need escape="false" in outputs anymore in order to prevent double-escaping and you do not need to worry about right presentation in inputs anymore. In JSF, everything is by default already XSS safe except when you redisplay user-controlled input with escape="false".

All in all, that IBM article is garbage as to modern Java Web Applications. The author seems to have decade old JSPs with scriptlets in mind.

See also: