On 2 February 2013 07:38, Ron Monzillo <ron.monzillo_at_oracle.com> wrote:
> 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).
Oops yes I said "authenticated user", but the sense of it is that a
GET request is uncovered and thus allowed and that is the non-sensical
issue.
> In addition to recommending that we adopt a different rule matching model,
> you are also suggesting that we adopt a different security model.
No. The current proposal is that when a new mode is activated,
then a request that does not match a method clause in the most
specific constraint is denied.
My proposal is that when a new mode is activated, then a request that
does not match any constraint is denied, but that it may match a less
specific path constraint if a more specific path constraint does not
apply because it's method clause does not match.
I am only proposing a change to the new mode and not the existing model.
To repeat my example:
"/*" - allow any authenticated user
"/admin/*" POST allow users in role admin
I am proposing that a request to GET /admin/something is controlled by
the /* constraint that does match it rather than being denied by the
/admin/* POST constraint that does not.
To me it is non-sensical that a non matching constraint effects the
handling of a request. Currently it effects it by allowing it, which
is dangerous. The current proposal inverts this to deny which is
safer, but just as non-sensical.
My proposal is to enable a mode where a non matching constraint has no
effect on request handling and the request is authorized by the most
specific matching constraint, or denied if there are no matching
constraints.
> 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,
I'm not proposing a change to the current security model. I'm just
proposing an extension to the new security mode that is being
proposed. Existing code and tests would continue to work as they do
today. This new mode would only be activated if the descriptor
tuned it on. Currently it is proposed that the new mode switches the
non matching of methods from allow to deny. I'm proposing that it
switches it to a fall through to a matching constraint and only if
there are no matching constraints is it denied.
Either way new tests and new applications will be written that will
use this mode.
--
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.