httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Roy T. Fielding" <field...@gbiv.com>
Subject Re: TRACE still enabled by default
Date Wed, 21 Mar 2012 19:33:50 GMT
On Mar 21, 2012, at 5:33 AM, Jim Jagielski wrote:
> On Mar 20, 2012, at 3:04 PM, Stefan Fritsch wrote:
> 
>> On Saturday 17 March 2012, Roy T. Fielding wrote:
>>>> We still enable TRACE by default.
>>>> 
>>>> 
>>>> 
>>>> Is this useful enough to justify making every other poor sap with
>>>> a security scanner have to manually turn it off?
>>> 
>>> Yes.
>>> 
>>>> I'm hoping 2.4.x is early enough in life where flipping this
>>>> wouldn't be too astonishing.
>>> 
>>> I don't change protocols based on fool security researchers and
>>> their failure to correctly direct security reports.  TRACE is not
>>> a vulnerability.
>> 
>> That doesn't mean that it's a good idea to have it on by default. I 
>> can't remember ever having needed it for debugging. While it may 
>> actually be useful in reverse-proxy situations, it is usually 
>> necessary to disable it there because one does not want to leak 
>> internal information like the private IPs from X-Forwarded-For.
>> 
>> It can also compound security issues in webapps. In general, one can 
>> say that it increases the attack surface a web server presents to the 
>> internet. I think it is a good idea to make it default to off.
>> 
> 
> I agree w/ Roy that having our defaults be non-compliant is
> bad, and actions which seem to imply that the idea that TRACE
> is a vulnerability is valid should be avoided.

TRACE won't work at all if the most popular end-point doesn't support it.

If folks want to protect clients (including gateways) against their own
stupidity regarding what they choose to send in a TRACE request, then
do so by selectively removing some lines from the response and I will
try to update the standard accordingly.

Turning it off by default is not an option.  I will veto that.

....Roy

Mime
View raw message