Jeff,
I'm fully supportive of being able to deny all requests and then use
specific constraints to allow specific requests through. I too believe that
the default allow-all-deny-specific behaviour of the container is unsafe -
but I think it is too late to correct that default (I tried for 2.5 and
3.0).
We did however, make a change in 3.0 that does allows simple implementation
of deny-all-allow-specific constraints. We now support "" being the
pattern that matches to root of the context, so I think best practise for
webapplication constraints is to have:
/* - deny all
"" - allow GET, HEAD
and then have other patterns allowing URLs and methods as need be ,for
example
/foobar/* allow authenticated GET, POST, HEAD
So a PUT request to /foobar/info will not match that constraint, but will
match the /* constraint and thus be denied. In 2.5, there was no way of
having a constraint match just the context root, so a /* forbidden
constraint could not be relaxed for the root. Thus the "" pattern makes
this style possible (if a little confusing that "" matches / and / matches
everything not matched by other patterns).
So at this stage, I think the best we can do is to try to educate users in
the best practise of deny-all-allow-specific constrain patterns
cheers
On 12 September 2012 09:41, Jeff Williams
<jeff.williams_at_aspectsecurity.com>wrote:
> Sorry about the scary sounding name. I'm not particularly a fan of the way
> vulnerabilities get named either.
>
> But it is a legitimate attack -- and what's misleading is the spec!
>
> Of course it's because the constraint is misconfigured. That's the point.
> Every developer I've talked with thinks that adding methods ensures that
> *only* those methods can be used. Even the example *in the spec* seems to
> support that interpretation. That's what they *want* - the ability to
> restrict access to a small known set of methods. And yes, most of the time
> they can make their app safe by removing the methods. But they still don't
> get exactly what they want.
>
> How many people do you think search for "web.xml security-constraint" and
> click on the first article...
> http://java.dzone.com/articles/understanding-web-security
>
> --Jeff
>
>
> -----Original Message-----
> From: Rémy Maucherat [mailto:rmaucher_at_redhat.com]
> Sent: Tuesday, September 11, 2012 4:04 AM
> To: jsr340-experts_at_servlet-spec.java.net
> Subject: [jsr340-experts] Re: Digest for list
> jsr340-experts_at_servlet-spec.java.net
>
> On 09/11/2012 04:14 AM, Jeff Williams wrote:
> > Personally, I would rather cause some applications to break and have a
> > servlet spec that's secure out of the box. But if that's not
> > possible, then Ron's proposal seems right.
> I was always against adding deny security in the Servlet security. The
> rules are very complex already so that many people don't understand them
> well, this is going to make things worse. So -1 for adding them.
>
> Your scary sounding "verb tempering" attack is not legitimate and quite
> misleading. If the Servlet is handling all HTTP methods as a GET, then it
> should be protected accordingly in security constraints, without using
> methods in there.
>
> Rémy
>
>
--
Greg Wilkins <gregw_at_intalio.com>
http://www.webtide.com
Developer advice and support from the Jetty & CometD experts.