Re: [XHR] XMLHttpRequest specification lacks security considerations

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