On 2/4/13 9:37 AM, Mark Thomas wrote:
> 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,
I agree that our containers should be able to detect
security configurations that feature uncovered methods.
It is also the case, that the users of your jar A will not be able to tell
whether the developers of jar A knew what they were doing.
An app, module, or fragment, that features uncovered methods at constrained
patterns should be seen as NOT following the proposed security
recommendations, and the users of such artifacts should expect, if not
demand,
that they evolve to do so. This is especially the case for widely used
fragments and
packages where logging of uncovered methods would be expected to aggravate
package users and raise questions best addressed by the package authors.
Where that creates a problem like that which you have composed, and
the assembler/developer wants to go ahead; then they will have to decide
whether they want to run with or without the flag, and whether they want
to take on
the task of defining the additional method protections, or perhaps
whether they
want to lean on a package developer to provide a version of the package
that follows the recommendations.
For many if not most applications, setting the flag by itself will deny
uncovered methods;
without interfering with the expected function of the app.
At this point, developers of applications should use the flag to impose
the recommendations, including on any fragments or packages used by
the app; which should accelerate detection of misconfigurations, and
adoption of the recommendations.
Ron
ps: any logging that might be done in the absence of the flag,
should also be done when the flag is set.