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
smime.p7s
Description: S/MIME cryptographic signature
