Re: [XHR] XMLHttpRequest specification lacks security considerations

On 9 Feb 2010, at 14:30, Anne van Kesteren wrote:

>> 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.

So let's identify the instances where we think more material is needed and look for volunteers.

> 
>>> 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.

You're right about that attack.

>> 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.

It's highly relevant to XHR, though, and therefore worth calling out.  Could we agree on that?

>>> 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.

So that's another open point that we need to find a volunteer for.

> 
>>>> 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.

Yes, of course.  My request was for a security considerations section that explains the interaction and says where what policy is defined. 

>> 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.

Are they documented for EventSource?

And if there's a common policy here, should this be a separate document?

Received on Tuesday, 9 February 2010 14:35:20 UTC