On 04/02/2013 14:08, Ron Monzillo wrote:
> 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."
OK. Now consider the following.
The developer of JAR A fully understands the Servlet 3.0 specification
and has included a web-fragment.xml that deliberately leaves methods
uncovered. These security constraints function exactly as intended and
desired. There is no security vulnerability. Using a default DENY
semantic for the uncovered methods will break the functionality provided
by JAR A.
The developer of JAR B does not fully understand the Servlet
specification and has included a web-fragment.xml that accidentally
leaves methods uncovered. These security constraints do not function as
intended. There is a security vulnerability. Using a default DENY
semantic for the uncovered methods will fix the vulnerability and have
no negative impact on the functionality provided by JAR B.
What is the developer of an application that requires both of these JARs
meant to do?
How will the developer of this application even know that there is a
problem? If anything, they will choose not to use this new feature
because it obviously breaks functionality provided by JAR A. How will
they know that an issue remains with JAR B?
How will this new feature help that developer?
Contrast this the the proposal to leave the definition of security
constraints unchanged and to require logging (that may be disabled) of
uncovered methods.
Mark