Re: [XHR] XMLHttpRequest specification lacks security considerations

On 8 Feb 2010, at 17:50, Anne van Kesteren wrote:

>>>> - Somewhat detailed considerations around CONNECT, TRACE, and TRACK (flagged in the text of the specification, but not called out in the security section; 4.6.1).
>>> 
>>> What is the reason for duplicating this information?
>> 
>> It will be useful for implementers and reviewers of this specification to find a brief summary of the relevant issues within the spec itself.  That doesn't imply that you simply need to "duplicate information".

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

> 
>>>> - Considerations around DNS rebinding.
>>> 
>>> Why would these be specific to XMLHttpRequest?
>> 
>> These indeed apply to just about any specification that uses a same-origin policy. But that's not a justification for ignoring them here.  DNS rebinding has been both obvious and overlooked for some 10-15 years, so reminding reviewers and implementers of both the security risk and the countermeasures would seem appropriate.
> 
> 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.  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.

>>>> - Some explanation for the "security reasons" that are mentioned in section 4.6.2 (setRequestHeader).
>>> 
>>> Maybe removing "security reasons" would be better?
>> 
>> No.  It's worth explaining why (a) we have a specific blacklist, and (b) what the impact of not having that blacklist is -- this is effectively profiling of the protocol elements that are accessible to applications; if I've seen a design decision that deserves a rationale in the spec, then this qualifies.
> 
> 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.

> 
>>>> - The rationale for the handling of HTTP redirects in section 4.6.4.
>>> 
>>> I agree that this should be clarified, though I do not see why it should be mentioned in a separate section as well.
>> 
>> It sounds useful to tell a single, consistent story about the security model around redirects, DNS rebinding, and same-origin policies, instead of scattering rationales through the spec.  Therefore, I'm in favor of covering these topics in a single security considerations section.
>> 
>>>> - The fact that this specification normatively defines the same-origin policy as it applies to network access within browsers (section 4.6.1; though that mostly refers to HTML5 these days)
>> 
>>> It does not define the policy. It just uses it.
>> 
>> It does not define what "same-origin" means.
> 
> That would be a bug in HTML5.

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

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


On 8 Feb 2010, at 18:14, Anne van Kesteren wrote:

> On Mon, 08 Feb 2010 18:01:18 +0100, Julian Reschke <julian.reschke@gmx.de> wrote:
>> Is re-binding == spoofing? Does <http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.15.3> help, or does nit need to be updated (Thomas; HTTPbis will gladly accept your input ;-).
> 
> As far as I can tell DNS rebinding is possible because clients observe TTL and can be prevented by servers carefully checking the Host header. The solutions clients can employ have potential drawbacks:
> 
>  http://en.wikipedia.org/wiki/DNS_rebinding
> 
> I.e. it seems to be something different.

correct

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

Received on Tuesday, 9 February 2010 11:13:54 UTC