On Tue, 09 Feb 2010 12:13:49 +0100, Thomas Roessler <[email protected]> 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/
