Proposed representation of "the flag" (in web-common_3_1.xsd.xml).
a new element would be defined for use in web.xml that when specified, would cause
a deny semantic to be applied to uncovered HTTP methods.
This new element would be defined within the web-common_3_1.xsd.xml
schema as follows:
<xsd:complexType name="web-appType">
<xsd:choice minOccurs="0" maxOccurs="unbounded">
<xsd:element name="module-name" type="javaee:string" minOccurs="0"/>
<xsd:group ref="javaee:web-commonType"/>
<xsd:element name="absolute-ordering" type="javaee:absoluteOrderingType"/>
<xsd:element name="deny-uncovered-http-methods" type="javaee:emptyType">
<xsd:annotation>
<xsd:documentation>
When specified, this element causes uncovered http methods
to be denied. For every url-pattern that is the target of a
security-constrant, this element causes all HTTP methods that
are not covered (by a security constraint) at the url-pattern
to be denied.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
</xsd:choice>
<xsd:attributeGroup ref="javaee:web-common-attributes"/>
</xsd:complexType>
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.
Ron
On 2/12/13 5:15 PM, Rajiv Mordani wrote:
> Mark,
> Please see comments in-line:
> On 2/12/13 3:18 AM, Mark Thomas wrote:
>> On 08/02/2013 19:49, Rajiv Mordani wrote:
>>> Mark,
>>> Ron has driven the security issues for servlet spec for both 3.0
>>> and 3.1 work so I am on board with the proposed solution from Ron at
>>> least to close
>>> the gap in the short term. We can revisit the more detailed security
>>> model
>>> changes in a future revision of the spec.
>>>
>>> - Rajiv
>> Rajiv,
>>
>> The discussion with Ron on the Servlet EG list over what exactly would
>> be in Servlet 3.1 took place in October last year. That discussion
>> appeared to reach agreement on the following points:
>>
>> 1. Logging should be required.
>
> Logging could be required but isn't sufficient given that it does not
> solve the problem IMO.
>
>>
>> 2. If logging was required, remeditation could be a container feature.
>
> Again this means that it is up to the container vendors to implement
> this feature, if at all and given that this has been raised as an issue
> by an external security group, I think we should address it beyond just
> logging and provide a mechanism.
>
>>
>>
>> Given Bill Shannon's recent post to the Servlet EG the discussion has
>> clearly been continuing without the Servlet EG. Please could you clarify
>> (particularly with respect to the above two points) what you intend
>> adding to Servlet 3.1.
>
> The platform EG in my opinion oversees the entire group and there have
> been
> other discussions from other EG that has carried over to the platform
> EG as
> well. This isn't the only special case so given that I think we should
> consider
> adding what Ron is proposing.
>
>>
>> As I have previously stated, I believe 1) is essential regardless of the
>> approach taken for remediation.
>>
>> Regarding 2) I'd be happy if remediation was left as a container feature
>> (as previously agreed with Ron in October last year) or included in the
>> specification as an optional feature / recommendation much like JSR 196
>> support is currently or HTTPS support was in the past.
>
> I don't think that it should be optional. It should be supported by
> all container
> vendors.
>
> - Rajiv
>
>
>>
>> Mark
>