Re: [XHR] XMLHttpRequest specification lacks security considerations

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.

>> - 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".

>> - 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.

>> - 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.

>> - 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.  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.

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.

> 
>> Related to this, what is the rationale for making the following (explicitly security-relevant) conformance clauses SHOULD, not MUST?
>> 
>> ** 4.6.1
>> 
>> If method is a case-sensitive match for CONNECT, TRACE, or TRACK the user agent should raise a SECURITY_ERR exception and terminate these steps.
>> 
>> If the origin of url is not same origin with the XMLHttpRequest origin the user agent should raise a SECURITY_ERR exception and terminate these steps.
>> 
>> ** 4.6.2
>> 
>> 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.

(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.)

Received on Thursday, 4 February 2010 16:22:29 UTC