Thanks Mark n Nick. As far as I see from w3af documentation, they are looking into options to show the allowedMethods. (As Nick guessed)
Mark, Can you suggest me an alternate way to prove that TRACE is not allowed on my webserver, if that's a possibly false positive. Thanks & Regards Sachin -----Original Message----- From: Nick Williams [mailto:nicho...@nicholaswilliams.net] Sent: Tuesday, February 19, 2013 12:47 AM To: Tomcat Users List Subject: Re: tomcat 7.0.22 - allowTrace="false" not working On Feb 18, 2013, at 1:11 PM, Mark Thomas wrote: > 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 Okay. This was a couple of years ago that I saw this, and it was Tomcat 6.0 at the time, so that would probably explain why I saw what I saw. It would not explain the false positive he is seeing on 7.0.22, since the entire 7.0.x branch has handled this correctly. Nick --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
