- From: Anne van Kesteren <annevk@opera.com>
- Date: Mon, 08 Feb 2010 17:50:53 +0100
- To: "Thomas Roessler" <tlr@w3.org>
- Cc: "W3C WebApps WG" <public-webapps@w3.org>, public-web-security@w3.org
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