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 <berdario@...il.com>
To: cve-assign@...re.org
Cc: oss-security@...ts.openwall.com
Subject: Re: CVE Request: CSRF in Grails console

Thanks

On Tue, Aug 2, 2016 at 11:43 PM,  <cve-assign@...re.org> 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,
> http://docs.grails.org/1.3.9/guide/single.html#6.4.5%20Mapping%20to%20HTTP%20methods
> 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: http://docs.grails.org/3.1.1/ref/Plug-ins/URL%20mappings.html

```
"/$controller/$action?/$id?"{
    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
https://github.com/sheehan/grails-console/blob/88b1bb2/grails3/app/grails-app/controllers/UrlMappings.groovy
(note that in fact their fix requires a CSRF token even for GET requests)

The reference app for the Grails in Action book:
https://github.com/pledbrook/graina/blob/fe1feca/hubbub/grails-app/conf/UrlMappings.groovy#L16-L20

( There are even people that proposed custom annotations to provide a
mechanism to constrain the methods closer to the actual
method/function definition:
http://burtbeckwith.com/blog/?p=80 ... 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