Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 3 Aug 2016 00:57:25 +0100
From: Dario Bertini <>
Subject: Re: CVE Request: CSRF in Grails console


On Tue, Aug 2, 2016 at 11:43 PM,  <> wrote:
> It is possible that a behavior like this could have its own CVE ID if
> it is undocumented or interacts incorrectly with run-app. For example,
> says "the HTTP method (GET, POST, PUT or DELETE)." Do you mean, for
> example, that the OPTIONS or TRACE method can allow access, but the
> documentation suggests that only GET, POST, PUT, and DELETE need to be
> anticipated?

Nothing that fancy (I actually forgot about the HTTP method mapping
you linked to...)

The template code dropped by `grails create-app` is the same one you
can see here:

    constraints {
        // apply constraints here

This code is then kept by Grails programmer, who only rarely add more
constrained mappings to this file, and instead relying on "convention
over configuration". That is: they add controllers, and every
non-private Closure/method defined in such controllers is accessible
via any HTTP method, unless the snippet above is not removed.

You can easily find demonstrations that this happens in real code:

The same Grails Console plugin
(note that in fact their fix requires a CSRF token even for GET requests)

The reference app for the Grails in Action book:

( There are even people that proposed custom annotations to provide a
mechanism to constrain the methods closer to the actual
method/function definition: ... I'd say that this is a simptom
of how there are several ways to constrain HTTP methods for each
controller, and yet none of these is truly used universally)

Powered by blists - more mailing lists

Your e-mail address:

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Powered by Openwall GNU/*/Linux - Powered by OpenVZ