Re: [XHR] XMLHttpRequest specification lacks security considerations

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.


> Section 3 should at the very least spell out:
>
> - 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?


> - Considerations around DNS rebinding.

Why would these be specific to XMLHttpRequest?


> - Some explanation for the "security reasons" that are mentioned in  
> section 4.6.2 (setRequestHeader).

Maybe removing "security reasons" would be better? Providing rationale for  
each part of the specification would make it very big.


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


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


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


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

Received on Sunday, 31 January 2010 13:23:43 UTC