Re: [XHR] XMLHttpRequest specification lacks security considerations

On Thu, 04 Feb 2010 17:22:16 +0100, Thomas Roessler <tlr@w3.org> wrote:
> On 31 Jan 2010, at 14:23, Anne van Kesteren wrote:
>> On Tue, 19 Jan 2010 08:01:12 +0100, Thomas Roessler <tlr@w3.org> wrote:
>>> With apologies for the belated Last Call comment -- the XMLHttpRequest  
>>> specification
>>>  http://www.w3.org/TR/XMLHttpRequest/
>>>
>>> ... doesn't have meaningful security considerations.
>>
>> I actually removed that section altogether in the editors draft.
>
> Strikes me as a step in the wrong direction.

Well, as you said, it didn't amount to much anyway.


>>> - Somewhat detailed considerations around CONNECT, TRACE, and TRACK  
>>> (flagged in the text of the specification, but not called out in the  
>>> security section; 4.6.1).
>>
>> What is the reason for duplicating this information?
>
> It will be useful for implementers and reviewers of this specification  
> to find a brief summary of the relevant issues within the spec itself.   
> That doesn't imply that you simply need to "duplicate information".

Well, I didn't mean it literally, but that's what it would come down to,  
no?


>>> - Considerations around DNS rebinding.
>>
>> Why would these be specific to XMLHttpRequest?
>
> These indeed apply to just about any specification that uses a  
> same-origin policy. But that's not a justification for ignoring them  
> here.  DNS rebinding has been both obvious and overlooked for some 10-15  
> years, so reminding reviewers and implementers of both the security risk  
> and the countermeasures would seem appropriate.

But you could e.g. do this kind of attack using <img> or <form> as well.  
It seems this problem should be pointed out in the HTTP specification.


>>> - Some explanation for the "security reasons" that are mentioned in  
>>> section 4.6.2 (setRequestHeader).
>>
>> Maybe removing "security reasons" would be better?
>
> No.  It's worth explaining why (a) we have a specific blacklist, and (b)  
> what the impact of not having that blacklist is -- this is effectively  
> profiling of the protocol elements that are accessible to applications;  
> if I've seen a design decision that deserves a rationale in the spec,  
> then this qualifies.

There is already a note that explains why we have this list. I removed  
"security reasons" therefore.


>>> - The rationale for the handling of HTTP redirects in section 4.6.4.
>>
>> I agree that this should be clarified, though I do not see why it  
>> should be mentioned in a separate section as well.
>
> It sounds useful to tell a single, consistent story about the security  
> model around redirects, DNS rebinding, and same-origin policies, instead  
> of scattering rationales through the spec.  Therefore, I'm in favor of  
> covering these topics in a single security considerations section.
>
>>> - The fact that this specification normatively defines the same-origin  
>>> policy as it applies to network access within browsers (section 4.6.1;  
>>> though that mostly refers to HTML5 these days)
>
>> It does not define the policy. It just uses it.
>
> It does not define what "same-origin" means.

That would be a bug in HTML5.


> It *is* the place that explains what policy applies to XMLHttpRequest,  
> and the redirect section is one example where the policy needs to be  
> refined for the specific case.

What do you mean with refined?


> So, without going into semantics of what "define the policy" means, I  
> suggest calling out that this spec sets the security policy for XHR,  
> what that policy is, how the different pieces that are relevant to it  
> tie together, and what the risks are.

To be honest, I'm not quite sure what I should write down with respect to  
this. I guess if someone has text that is accurate we could opt into using  
it.


>>> For security reasons, these steps should be terminated if header is an  
>>> ASCII case-insensitive match for one of the following headers:
>>> ...
>>
>> Early on we agreed that all security-relevant conformance clauses  
>> should be SHOULD and not MUST so that implementors could ignore them in  
>> specific contexts. E.g. extensions. I would personally be fine with  
>> making these MUST.
>
> I'd be significantly more comfortable with a MUST, and wonder whether  
> the extension considerations have changed over time.  *If* we stick to  
> SHOULD, some analysis of the combined effects of different choices would  
> be in order.

Changed to MUST.


> (Considering the discussion around cross-origin XHR over the past two or  
> three years, I suspect that we've had a (partial) change of attitude  
> around playing with different security models for the API.  Hence, I'd  
> like us to reconsider that particular decision.)

I'm not sure what you're saying here. Is this a reference to the UM/CORS  
discussion? What do we need to reconsider in addition to what is already  
under discussion?


-- 
Anne van Kesteren
http://annevankesteren.nl/

Received on Monday, 8 February 2010 16:51:29 UTC