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
