Re: TRACK, was: LC comments.

Jonas Sicking wrote:
>> I don't see why.
>>
>> A client that tries TRACE is likely to exploit an IIS weakness, and if 
>> the UA blocks it, the client is getting what it deserves (an exception).
> 
> Or they have implemented something completely unrelated in their server 
> that just happens to be called TRACE and are confused why they can't 
> interact with it using XMLHttpRequest.

Which would mean that a non-normative appendix telling the story about 
the risk related to TRACE (and TRACK) would be helpful.

>> On the other hand, why would we want to hardwire this requirement into 
>> the spec? As far as I can tell, mentioning TRACE in this prominent 
>> place already causes way more confusion than not mentioning it would 
>> ever cause.
> 
> I think that is due to insufficient explanation in the spec of why the 
> method is there.

For the record, I meant to say "TRACK", not "TRACE". But you are right, 
even for "TRACE" it's not obvious except to people who already are aware 
of the risk.

>>> If you want to put this as a Note in the spec, or as a normative part 
>>> of the spec matters less to me. However I don't see a reason not to 
>>> make it normative since it's not going to change for any web browser.
>>
>> It just doesn't belong here.
>>
>> UAs are already allowed to reject anything they want for security 
>> concerns, so making it *mandatory* to do so for a method that even 
>> isn't documented is really strange.
> 
> That line of reasoning would mean that we shouldn't put any security 
> restrictions in the spec and then just tell UAs to deal. There are 
> several downsides with that:
> 
> 1. Users would get annoyed when running into the restrictions that don't
>    show up in the spec.

Like PROPFIND not working (IE7), or silently rewritten to "GET" or 
"POST" (Opera)?

Yes, I do agree that explaining this is useful, I just don't see why 
it's necessary to make it a normative requirement, and put it into the 
API documentation.

An appendix would be completely sufficient.

> 2. It gets harder to build future specs on top of this spec since you
>    can't by looking at the XHR spec tell what works and what doesn't

It doesn't tell you that anyway, as some implementors have chosen a 
white-list approach to extension methods.

> 3. Many UAs would likely miss some of the security aspects and would
>    therefore be exploitable.

In this case, it's not the UA, but IIS 5.1 that is exploitable.

BR, Julian

Received on Friday, 13 June 2008 19:01:58 UTC