Sorry but my proposed convention for deny-all-allow-specific does not
actually work if methods are included as constraints are matched to the
most specific first.
A request to /foobar/info with an unknown method would match only the
/foobar/* constraint and then not be constrained because it does not match
the methods listed.
In order for such a scheme to work, the deny-all constrain would need to
add /foobar/* to it's URL patterns and have a method exceptions for GET,
POST and HEAD.
I guess this is evidence that the method matching of constraints is indeed
very confusing.
Prior to 2.5, Jetty used to match a request to the most specific constraint
with a matching method, but the new rules for combining constraints made
that no longer possible to do.
regards
On 12 September 2012 13:19, Greg Wilkins <gregw_at_intalio.com> wrote:
>
> 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.
>
--
Greg Wilkins <gregw_at_intalio.com>
http://www.webtide.com
Developer advice and support from the Jetty & CometD experts.