On 2/4/13 6:09 AM, Mark Thomas wrote:
> On 30/01/2013 20:19, Bill Shannon wrote:
>> 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.
> A number of issues have been highlighted with this proposed change.
>
> 1. What happens when security constraints are included for a fragment
> with one value for this new setting and the security constraints for the
> main web.xml are written for the other value?
Mark,
the proposal is explicit on this -
"This element would only be available via the top level deployment
descriptor,
web.xml. When specified in web.xml, this element would apply to all security
constraints defined for the web application; including any defined in
fragments.
This element would apply to uncovered methods resulting from the
specification
of security constraints via the web.xml and web-fragment deployment
descriptors, from the use of the @ServletSecurity annotation, and from
the use
of the setServletSecurity method of the ServletRegistration interface."
> 2. Complexity. Given the amount of time it took the Servlet EG to get
> its head around this proposal and that the EG is meant to have a very
> good grasp of the specification how realistic is it to expect that users
> are going to understand a security model even more complex that the one
> we have already?
>
> 3. A significant factor in justifying this change was verb tampering. As
> already explained that is an issue with the JSP specification (with a
> fix in hand) not the Servlet specification.
>
> This proposal is aimed at addressing an increasingly limited issue that
> the specification already has the features in place for users to address
> and does so by making a complex feature already more complex. That does
> not strike me as a sensible thing to do.
>
> I'd support a change to the specification that required the container to
> log potential issues along with a pointer to the section of the
> specification that explains how to avoid them using the currently
> available features.
As you know, I also agree that uncovered methods should be logged.
Ron
> Mark