W3C home > Mailing lists > Public > public-web-security@w3.org > February 2010

Re: [XHR] XMLHttpRequest specification lacks security considerations

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
Message-ID: <op.u7u3skax64w2qv@annevk-t60>
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  

>>> 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
Received on Tuesday, 9 February 2010 13:30:51 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:26:17 UTC