Greg Wilkins wrote on 02/14/13 18:42:
> On 13 February 2013 09:15, Rajiv Mordani <rajiv.mordani_at_oracle.com> wrote:
>> Logging could be required but isn't sufficient given that it does not
>> solve the problem IMO.
>
> But the proposal also does not solve the problem. By default
> nothing changes and vulnerable webapplications will remain vulnerable.
> Nobody has explained why the deny-uncovered-http-methods is any more
> likely to be used that adding method ommission constraints?
>
> To use the proposal requires that somebody who is aware of the problem
> also has permission to edit the web.xml. Such a person is equally
> able to add method ommission constraints to address the vulnerability,
> so I just don't see how it will significantly change how the number of
> vulnerable webapplications.
>
> On the otherhand, if we recommend that optional deny semantics are a
> container feature, then it would be possible for deployers without
> permission to edit web.xml to switch the feature on. It could even be
> the default mode for containers to deploy webapps. I see this
> approach as much more likely to reduce the number of vulnerable web
> apps deployed.
In addition to Ron's proposal that allows application developers to
choose this behavior, I would be happy to allow the Servlet container
to have a configurable option to control this behavior. Something
like this:
A Servlet container may provide a configurable option to
select whether the default behavior for uncovered methods
is ALLOW or DENY. This option may be configured on a
per-application granularity or larger. Note that setting
this default to DENY may cause some applications to fail.
I think it's useful to give both administrators and application
developers control over this behavior.