I do agree this is an important security issue that needs to be fixed
and I think that the proposed deny semantics allows for mode that is
less surprise for developers. However, I'm wondering if there is one
step better we could go.
Currently if we have the following constraints:
"/*" - allow any authenticated user
"/admin/*" POST allow users in role admin
then we have the strange effect that a GET to /admin/* is an uncovered
method and is allowed without the application of the /* constraint
allowing a GET by any authenticated user. This is surprising and a
mistake that I personally have made several times.
My understanding of the deny-uncovered-http-methods proposal is that
this will change the behaviour so that a
GET to /admin/* will be denied ( I assume this means a 403 ). While
I find this less surprising than the current implementation, I still
find it strange that a constraint that specifies a method affects
methods that do not match it.
If we are to introduce better mode for security constraint modes, then
I would like to see it operate as follows:
+ A request that does not match any security constraint is denied
+ A request will be constrained by the constraint with the most
specific url-pattern and a matching method. The effect should as if
all constraints with non-matching methods are removed from the
constraint collection.
So rather than simply deny uncovered methods, we allow constraints
with less specific URL pattern to apply and only if there are no such
constraints do we deny the request.
I think this is the most intuitive interpretation of security
constraints and if we are going to provide an alternative mode then it
should be the best mode we can design and not just slam the door on
one particular issue.
regards
On 31 January 2013 07:19, Bill Shannon <bill.shannon_at_oracle.com> wrote:
> Some time ago Oracle proposed a new Servlet option to change the default
> semantic for uncovered HTTP methods from ALLOW to DENY. This proposal
> was meant to address a potential security issue in the Servlet spec
> pointed out by Jeff Williams of Aspect Security and OWASP.
>
> While proper use of the Servlet security options results in no security
> issues, it's far too easy to use the Servlet security options improperly.
> This proposal addresses an "ease of use" issue related to security, not
> a correctness issue.
>
> My understanding is that many members of the Servlet expert group rejected
> this proposal, because there is no actual security hole that this fixes,
> and because the fix seemed to make the security model more complex.
>
> I raised this issue in the Java EE platform expert group for discussion.
> Many experts felt strongly that this is a real issue that should be
> addressed in the Servlet spec, and that the proposed solution was an
> appropriate way to address the issue. No one in the platform expert
> group objected to the proposed solution.
>
> I'm sure you're aware that security issues in the Java platform are
> receiving additional attention lately. While addressing this issue
> is only one small step, we and others feel it is an important one.
> Unless a technical flaw is discovered in the proposed approach, we
> intend to include this in Servlet 3.1.
>
> Thank you.
>
> Bill Shannon
> Java EE Spec Lead
--
Greg Wilkins <gregw_at_intalio.com>
http://www.webtide.com
Developer advice and support from the Jetty & CometD experts.
Intalio, the modern way to build business applications.