XSS (Cross Site Scripting) became a favored attack method in the last years. Several things are possible using an XSS vulnerability ranging from small annoyances to a complete desaster.
The XSS prevention cheat sheet states 6 rules to prevent XSS attacks. For a complete solution output encoding is needed in addition to input validation.
Here I take a further look on how to use the built in encoding methods in grails applications to prevent XSS.
Take 1: The global option
There exists a global option that specifies how all output is encoded when using ${}. See grails-app/conf/Config.groovy:
// The default codec used to encode data with ${} grails.views.default.codec="html" // none, html, base64
So every input inside ${} is encoded but beware of the standard scaffolds where fieldValue is used inside ${}. Since fieldValue uses encoding you get a double escaped output – not a security problem, but the output is garbage.
This leaves the tags from the tag libraries to be reviewed for XSS vulnerability. The standard grails tags use all HTML encoding. If you use older versions than grails 1.1: beware of a bug in the renderErrors tag. Default encoding ${} does not help you when you use your custom tags. In this case you should nevertheless encode the output!
But problems arise with other tags like radioGroup like others found out.
So the global option does not result in much protection (only ${}), double escaping and problems with grails tags.
Take 2: Tainted strings
Other languages/frameworks (like Perl, Ruby, PHP,…) use a taint mode. There are some research works for Java.
Generally speaking in gsps three different outputs have to be escaped: ${}, <%%> and the ones from tags/taglibs. If a tainted String appears you can issue a warning and disallow or escape it. The problem in Java/Groovy is that Strings are value objects and since get copied in every operation so the tainted flag needs to be transferred, too. The same tainted flag must also be introduced for GStrings.
Since there isn’t any implementation or plugin for groovy/grails yet, right now you have to take the classic route:
Take 3: Test suites and reviews
Having a decent test suite in e.g. Selenium and reviewing your code for XSS vulnerabilities is still the best option in your grails apps. Maybe the tainted flags can help you in the future to spot places which you didn’t catch in a review.
P.S. A short overview for Java frameworks and their handling of XSS can be found here
@Take 1:
The problem with double encoding may no longer be present, depending on your grails version.
As of grails 2.1.5 the fieldValue function only encodes its output if called in tag form.
See:
https://github.com/grails/grails-core/blob/2.1.x/grails-plugin-gsp/src/main/groovy/org/codehaus/groovy/grails/plugins/web/taglib/ValidationTagLib.groovy#L475
https://github.com/grails/grails-core/blob/2.1.x/grails-plugin-codecs/src/main/groovy/org/codehaus/groovy/grails/plugins/codecs/HTMLCodec.java#L46-L47
(since cannot find any timestamp i’d say: this blogpost needs some kind of time info attached to it, to convey the degree of its outdatedness)
Thank you for the update. You are right. This post is from 2009 (see the URL for example).