tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sachin" <sac...@nitman.co.in>
Subject RE: tomcat 7.0.22 - allowTrace="false" not working
Date Tue, 19 Feb 2013 14:46:05 GMT
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:sachin@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:nicholas@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message