Further to my investigation,
I tried sending TRACE method with telnet
telnet localhost 8080
TRACE / HTTP/1.1
A: b
C: d
Host: localhost
With tomcat 7.0.22, it always returned 'HTTP/1.1 404 Not Found' response,
even with allowTrace="true".
But when I tried this with tomcat 5,
1. by default it gave me 200 (OK), which suggests TRACE is allowed by
default.
2. after adding allowTrace="false", it returned a nice 'HTTP/1.1 403 TRACE
method is not allowed'
So, in short, tomcat 5 gave me the described behavior correctly, but not
tomcat 7 with this approach.
Thanks & Regards
Sachin
-----Original Message-----
From: Sachin [mailto:sac...@nitman.co.in]
Sent: Tuesday, February 19, 2013 8:14 AM
To: 'Tomcat Users List'
Subject: RE: tomcat 7.0.22 - allowTrace="false" not working
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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
