Re: (XMLHttpRequest 2) Proposal for cross-site extensions to XMLHttpRequest

On Thu, 13 Apr 2006, Mark Nottingham wrote:
> 
> On 2006/04/11, at 1:37 PM, Ian Hickson wrote:
> > We could get around even this by requiring two additional headers --
> > 
> >    Request-Nonce: 2957219521
> > 
> > ...in the request, with a matching:
> > 
> >    Response-Nonce: 2957219521
> > 
> > ...in the response, which must match. This would cause issues with 
> > caches, but would basically make it impossible to cause a server to 
> > respond unless it actually wants to (we would prevent those two 
> > headers from being set as well).
> 
> This would effectively kill caching, and require two interactions for 
> every cross-site request.

We could get around that too by definining rules for how you cache such 
requests, but frankly I don't think the attack vector this would protect 
against is a particularly important one.


> The right way to do this is with OPTIONS, but there's very poor Web 
> server support for it.

OPTIONS is one of those features that was very nice in theory but is dead 
in practice. We can't realistically rely on it.



> > Known locations was a design mistake for robots.txt, it was a design 
> > mistake for favicon.ico, and it was a design mistake for p3p.xml. 
> > Let's not make a fourth design mistake.
> 
> They are, but there isn't any other option on the table yet.

Well, there is my proposal...

> This proposal has some nice attributes, but it's very complex.

I think it is simpler (a lot simpler) than a system based on a known 
location, with its own file format, etc. This is especially the case given 
that we need <?access-control?> anyway -- my proposal is just an 
additional set of rules for how to restrict XMLHttpRequest in a way that 
relies on that separate spec, and is describable in a few paragraphs.


> If it were me, I'd be inclined to put a known location in the WD (say, 
> /w3c/access-control) in order to get the TAG -- or anybody else -- 
> motivated to come up with a better solution.

That's a very dangerous way of designing specs. You are most likely to end 
up having implementations of your straw man.


> How about an Open Source apache module and ISS plug-in to give users 
> control of OPTIONS responses?

I agree that would be ideal. Realistically, it won't happen.


> By that time the side effects have already happened on the server side. 
> Many CGI tools (unfortunately) treat GET query args and POST bodies as 
> equivalent, so there will be situations where it's possible to craft an 
> attack against a server whereby a GET has side effects.

This is out of scope for this proposal since it is already possible to do 
both GET and POST submissions to arbitrary URIs without any protection 
whatsoever. The XMLHttpRequest cross-site protection only needs to protect 
against two things:

 1. Actually reading the data that is returned, and

 2. Sending of request entity body payloads that are MIME types other than 
    text/plain, multipart/form-data, application/x-www-form-urlencoded, 
    and application/x-www-form+xml.

The second is only to protect against hypothetical servers that are 
actually checking the Content-Type of submissions. In practice I doubt 
it'll make the slightest difference.

My proposal actually protects more than that, it protects against reading 
the returned data and _any_ entity payloads. This is overkill, but makes 
the model simpler. (The extra roundtrip is only required for the second of 
these, which is probably overkill. We could probably drop it.)


> > > 3) "Domain:" doesn't seem like the greatest name for something that 
> > > includes more than a DNS domain name, but I guess we can pretend it 
> > > means "security domain" or something.
> > 
> > I am not in any way attached to any of the names, I don't mind better 
> > names, e.g. if we want Security-Domain: or whatever.
> 
> I personally like Referer-Domain, as it is similar to the existing 
> Referer header (in fact, duplicitous, but whatever).

Referer has path information, which is a privacy problem; Referer-Domain 
would only include the domain, to get around this. (And the scheme, to 
allow for checks against DNS spoofing, but that's a minor detail.)


> WRT the Access-Control header, it should probably be 
> Content-Access-Control, as it's an entity header.

That works too.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Friday, 14 April 2006 00:06:40 UTC