users@servlet-spec.java.net

[servlet-spec users] [jsr340-experts] Re: Re: Re: Configuring DENY semantic for uncovered HTTP Methods

From: Rajiv Mordani <rajiv.mordani_at_oracle.com>
Date: Tue, 12 Feb 2013 14:15:36 -0800

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