Re: HTTP TRACE issues (text-only)

["Roy T. Fielding" <fi...@apache.org>]

There is no reason to discuss this on the security or pmc lists.

> Which brings us back to the start... How should we address this, umm...
> concern. Seems to me the 3 options are:
>
>     1. (continue to) Ignore it.

As far as the XSS concern, I'd ignore it.  However, it is perfectly
reasonable for server owners to want to allow or disallow this thing,
provided that the default is allow.

>     2. Address it via documentation (and relay our
>        POV regarding the risks associated)

I would include a link to the response that other person made to
the original bugtraq posting, but I don't have it.

>     3. Add AllowTrace enable|disable

AllowTRACE yes|no     (not available in .htaccess)

The "right" way to implement it would be to have the input filter
retain the original message as a read-only brigade and have the
parsed headers be a data structure that simply pointed to
places in that buffer, but that is obviously not feasible for 1.3
and won't even work efficiently with 2.0.  That would allow TRACE
to be implemented in a module.

In any case, disabling TRACE will not make a site more secure.

....Roy

Re: HTTP TRACE issues (text-only)

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

At 05:50 PM 2/24/2003, Roy Fielding wrote:
>There is no reason to discuss this on the security or pmc lists.

Agreed.  I agree so much I've pushed two other published issues off
of the security list :-)  We really aren't a star chamber, we only discuss
privately what cannot be discussed publicly, without compromising sites
by revealing unpublished vulnerabilities.

>>Which brings us back to the start... How should we address this, umm...
>>concern. Seems to me the 3 options are:
>>
>>    1. (continue to) Ignore it.
>
>As far as the XSS concern, I'd ignore it.  However, it is perfectly
>reasonable for server owners to want to allow or disallow this thing,
>provided that the default is allow.

I absolutely agree that WhiteHat has created mountains out of plains
(there wasn't even a mole to make a hill.)  One of their recommendations?

"Disable or disallow the TRACE Request method on production 
and development (unless needed) web servers."

Hmmm, "unless needed".  So everywhere this is needed (to discover proxy
loops and diagnose other proxy behaviors) the XSS vulnerability remains.
We all know how frequently 80% of the web servers are actually patched
or updated (annually or less frequently.)

It's absurd to lay this on the laps of the server developers who are doing
nothing other than echoing exactly what was requested from our box.
"Poor planning of the client does not constitute an emergency of the
server".  Bah.

So see my comments to 3. below for the real issue...

>>    2. Address it via documentation (and relay our
>>       POV regarding the risks associated)
>
>I would include a link to the response that other person made to
>the original bugtraq posting, but I don't have it.

Thom's forward to our list; Message-ID: <20...@samizdat>

>>    3. Add AllowTrace enable|disable
>
>AllowTRACE yes|no     (not available in .htaccess)

Well, I think we are missing one.  Michael Johnson posited to the list
at 09:53 AM 1/23/2003:

>Say you have a reverse proxy server in front of your web server. If you do a
>trace to the reverse proxy server that would execute the trace on the web
>server revealing that information. 

I consider that there are really three possibilities...

AllowTrace yes|all | noforward | no|none

The default would remain yes.

AllowTrace noforward would provide a response that this was the is
the authoritiative origin server.  No TRACE requests would be passed
through the proxy module.  This prevents reverse proxies from revealing
their roles in processing the request.

Having reread the RFC - TRACE "should" be implemented.  Not "must".
It's trivial to respond 405 MethodNotAllowed.

But what do we do, and what should we do, when the machine we proxy
returns 405?  Do we propagate it undisturbed to the client today?  It seems 
that would be the correct behavior.

>The "right" way to implement it would be to have the input filter
>retain the original message as a read-only brigade and have the
>parsed headers be a data structure that simply pointed to
>places in that buffer, but that is obviously not feasible for 1.3
>and won't even work efficiently with 2.0.  That would allow TRACE
>to be implemented in a module.

Probably not.  In any case, we should probably drop LIMIT as a legit
value to <Limit[except] >, and provide a warning (not a fatal error)
that cautions the user "The <Limit LIMIT> directive was ignored, see
the AllowLIMIT directive".  This would alleviate much confusion by users.

>In any case, disabling TRACE will not make a site more secure.

Precisely.

Bill