On 18/02/2013 19:03, Nick Williams wrote:
On Feb 18, 2013, at 12:55 PM, Mark Thomas wrote:
On 18/02/2013 18:19, Sachin wrote:
I'm testing it with w3af(http://w3af.sourceforge.net) since that's what our
security certifying vendor tests application against.
And it logs - The URL "http://localhost:8080/app/"; has the following
allowed methods: GET, HEAD, OPTIONS, POST, TRACE. This information was found
in the request with id 19.
That looks like a false positive although I'm not sure how it is happening.
You'd have to dig into the test to look at the HTTP request and response
headers to see what is goign on.
Mark
IIRC, I think I witnessed a while back Tomcat report that TRACE was allowed in
an OPTIONS request, but then refuse the request when an actual TRACE was made.
I've also seen this happen with PUT. Perhaps w3af is taking the OPTIONS
response at face value instead of actually testing whether a TRACE request is
allowed? I would suggest that w3af should do both, but I would also suggest
that Tomcat should not include TRACE in the OPTIONS response if TRACE is really
disallowed, and likewise for the other methods.
No supported Tomcat version has behaved that way for over three years
including the entire of the 7.0.x branch.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
