- From: Anne van Kesteren <annevk@opera.com>
- Date: Tue, 09 Feb 2010 14:30:10 +0100
- To: "Thomas Roessler" <tlr@w3.org>
- Cc: "Julian Reschke" <julian.reschke@gmx.de>, "W3C WebApps WG" <public-webapps@w3.org>, public-web-security@w3.org
On Tue, 09 Feb 2010 12:13:49 +0100, Thomas Roessler <tlr@w3.org> wrote: > On 8 Feb 2010, at 17:50, Anne van Kesteren wrote: >> Well, I didn't mean it literally, but that's what it would come down >> to, no? > > Again, please explain within the spec what the security reasons are for > this specific profile of HTTP. It'll help people understand the spec a > few years down the road. I'm not an expert on the reasons so I'd prefer not to. I believe I already mentioned that if someone writes text it could be taken in. >> 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. > > <img> or <form> permit you to place HTTP requests cross-origin anyway. Well yes, but with this attack you can also read the response, at least with <form> and an <iframe>. Unless I'm missing something. > The point here is that, if the server doesn't check host headers, then > DNS rebinding lets you place requests to some other server that you're > not supposed to be able to place. That's worth pointing out here. It is a general problem and not at all specific to XMLHttpRequest. >> There is already a note that explains why we have this list. I removed >> "security reasons" therefore. > > "The above headers are not allowed to be set as they are better > controlled by the user agent as it knows best what value they ought to > have." > > That's hardly an explanation. When I added that I requested a better note but so far I have not gotten anything. >>> 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? > > I think we have a case of too many "its" here. > > HTML5 explains when two origins are the "same". That comparison gets > applied in a number of policies: > > - navigation policy > - same-origin policy for cross-frame scripting > - XMLHttpRequest > > It's reasonable for the XMLHttpRequest specification to define the > same-origin policy when it's applied to placing HTTP requests; it's also > reasonable to explain in the XMLHttpRequest specification how an HTTP > client should behave with respect to redirects when it's operating under > that policy. It's not clear to me that this kind of material would > actually belong in HTML5. XMLHttpRequest already explains how a client should behave in face of redirects or normal requests. > However, please write up a coherent story that says (roughly) "we're > defining the application of this policy to HTTP, the critical pieces > where it shows up in this specification are the following, and here are > the specific security considerations we thought about when we wrote this > down." The security stuff is based on what implementations did or advice from people who do research in this area. If anything needs to be said in the specification I would probably not be the right person to do it. >>> HTML5 defines when two origins are the same, but it's remarkably >>> silent about the so-called "same-origin policy". The information may >>> be there, but it#s not obvious where it is. >> >> I think you are right in that it does not actually explain what it is. >> You filed a bug on the matter so hopefully it gets resolved in due >> course. > > See above. "The" same-origin policy consists of a sufficient number of > building blocks that it might be reasonable to keep some of them in a > spec like XMLHttpRequest. I'm not convinced, e.g. EventSource faces exactly the same issues. -- Anne van Kesteren http://annevankesteren.nl/
Received on Tuesday, 9 February 2010 13:30:50 UTC