On 15/02/2013 02:42, Greg Wilkins wrote:
> 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?
+1
> To use the proposal requires that somebody who is aware of the problem
And without logging no-one will be aware there is a problem. The first
step in fixing this issue is mandatory logging of it when it occurs.
> 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.
I believe the argument (that I don't support) is that the new switch is
simpler to use than adding the method ommission constraints.
> 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.
I hadn't considered the case where the web.xml could not be modified.
That is certainly a category of issue I see regularly on the users list
although it usually appears in the form of "I'm not allowed to modify
the web application in any way so I can't rename the WAR file".
This is another point in favour of making this an (optional) container
feature.
Mark