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
|