On Tue, 19 Jan 2010 08:01:12 +0100, Thomas Roessler <t...@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/
