On 2/1/13 5:47 PM, Greg Wilkins wrote:
> 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.
As I wrote:
. The Servlet security model is a path model designed to secure the
paths used to access Servlets.
As such, it is analogous and closely aligned with the Servlet mapping
model. In both, the
best matching algorithm is based only on url-pattern.
. The proposal does not seek to create two models or even two modes.
It's pupose is to
provide a simple way to cause there to be an explicit protection
specification for all HTTP methods
at all constrained url-patterns. Applications that follow the
recommendations for
defining security constraints, (e.g.,
http://docs.oracle.com/javaee/6/tutorial/doc/gmmku.html)
will feature no uncovered methods, and WILL BEHAVE EXACTLY THE SAME
INDEPENDENT OF THE
SETTING OF THE PROPOSED FLAG.
. Our tck and our examples must evolve in support of our security
recommendations; including
the recommendation that applications define explicit protection for all
HTTP methods at all
constrained patterns. We should also ensure that platforms satisfy any
new container requirements
designed to ensure that developers are informed when they have defined
an security configuation
that features uncovered methods.
Ron