Serious XSS vulnerability in Grails

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Serious XSS vulnerability in Grails

Andrew Todd
Yet another example of "insecure by default." Please see my comments in the JIRA thread.

http://jira.grails.org/browse/GRAILS-7170
Reply | Threaded
Open this post in threaded view
|

Re: Serious XSS vulnerability in Grails

alxndrsn
Interesting.  Are fixes for things like this backported, or only
available in new releases?

On 5 April 2013 00:19, Andrew Todd <[hidden email]> wrote:
> Yet another example of "insecure by default." Please see my comments in the
> JIRA thread.
>
> http://jira.grails.org/browse/GRAILS-7170

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Serious XSS vulnerability in Grails

Lari Hotari -

Hi,

I've renamed the issue http://jira.grails.org/browse/GRAILS-7170 to "XSS vulnerability: g:message doesn't escape message arguments" (the original title was too broad).
I believe the fix for that problem should be backported to all actively maintained Grails versions.

As an answer to your question about backporting fixes, we currently don't have plans to backport the new XSS prevention solution ( http://jira.grails.org/browse/GRAILS-9906) as a whole since it's a major change. Technically it's possible of course.

I have also added a new jira issue: http://jira.grails.org/browse/GRAILS-9975 "XSS prevention solution: Force all output to be "html safe" a bit like Rail3 SafeBuffer does".
That has been on my todo list for Grails 2.3 and that's one of the reasons I've ended up with the current architectural solution.

"Secure by default" is one of the goals of the new XSS prevention solution in Grails 2.3:
Out of the box, apps and plugins should be immune to such XSS attacks, unless the developers explicitly take action to change the default behaviour.
(vision statement inĀ  "https://github.com/grails/grails-core/wiki/Default-Codecs" , written by Marc and Peter)

The new XSS prevention solution in Grails 2.3 will make it easier to write safe web apps, but it will never be able to solve that problem on the behalf of the developer.

Please add your input to the Grails 2.3 XSS prevention solution on grails-dev mailing list:
http://grails.1312388.n4.nabble.com/Grails-2-3-encoding-escaping-xss-prevention-improvements-tp4642167p4643181.html

Grails is an open source project and I hope more developers could get involved in grails-core development. Let's make it easier to write safe webapps with Grails!
Your feedback and contributions are welcome!


Regards,

Lari



05.04.2013 11:17, Alex Anderson wrote:
Interesting.  Are fixes for things like this backported, or only
available in new releases?

On 5 April 2013 00:19, Andrew Todd [hidden email] wrote:
Yet another example of "insecure by default." Please see my comments in the
JIRA thread.

http://jira.grails.org/browse/GRAILS-7170
---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email