On Thu, 04 Feb 2010 17:22:16 +0100, Thomas Roessler <t...@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 <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.
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/
