Hi Greg,
Thanks for agreeing that we need to fix this issue.
On 1/31/13 4:14 PM, Greg Wilkins wrote:
> 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.
the above would allow GET by any user (independent of authentication).
> 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.
Servlet defines a best-matching url-pattern constraint model. If a pattern
is not constrained, it has no protections on it. If a pattern is
constrained, then
we determine what protection, if any, has been defined for the method of
the request.
If no protection applies to the method of the request, the method is
unconstrained
(at the pattern).
The flag provides a simple way to change the method protections that
are associated with constrained url-patterns (in the special case where
protection has not otherwise been defined for every HTTP method).
The flag would not change the constraint matching and enforcement model.
The constraint matching and enforcement model is analogous and closely
aligned with the Servlet mapping model, wherein a servlet is selected
from the servlet-mapping containing the best matching url-pattern, after
which, the handling of the HTTP method of the request is defined by
the selected servlet. This alignment is most evident in the use of the
@WebServlet and @ServletSecurity annotations, wherein the url-patterns
specified for the servlet-mapping become the patterns to which the
method protections defined in the annotation are applied.
for example:
@WebServlet(urlPatterns = {"/service/*"})
@ServletSecurity(value = @HttpConstraint(rolesAllowed = {"users"}))
public class ServiceServlet extends HttpServlet {...}
> 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.
In addition to recommending that we adopt a different rule matching model,
you are also suggesting that we adopt a different security model.
In your proposal, the initial state is everything is denied, and then you
require the developer to define what you call constraints, to allow
things to become allowed. Such a model would typically be referred to as
a permission
model, where what is specified relaxes restrictions that would otherwise
apply.
A proposal that inverts the security model, while also being less
clearly aligned with the
Servlet mapping model, embodies lots of impedance with the servlet
mapping facilities,
compatibility tests, implementations, and applications.
The premise of the current proposal is that we have a constraint model,
that is complete and correct, for which we have compatibility tests,
compatible implementations, and dependent applications. We want to preserve
all that while making it easy to ensure that there are no gratuitously
unprotected
HTTP methods at constrained patterns.
Ron
ps: Earlier in this discussion, we had developed some consensus around
some high level recommendations on the use of the constraint model; the
first
of which was that developers should attempt to define their
security-constraints
without naming HTTP methods, and thus such that they apply to all the HTTP
methods at the constrained patterns. In the case where developers cannot
heed that advice, our second recommendation was that they account for
all methods
at the constrained patterns. With the introduction of the flag, we
would be giving them a
simple way to do that in a very conservative manner (i.e., to deny all
methods for
which they have not defined a specific protection ).
To help guide web developers, the EE tutorial writers have recently
published the
following
recommendations
http://docs.oracle.com/javaee/6/tutorial/doc/gmmku.html
> 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