[whatwg] ContextAgnosticXmlHttpRequest: an informal RFC

[Hallvord Reiar Michaelsen Steen]

On 21 Mar 2005 at 17:57, Chris Holland wrote:

> The X-Allow-Foreign-Hosts header we were talking about earlier,
> wouldn't lend itself to much granularity on specific resources.

I'm not sure what you mean by that - the header can be sent with a 
specific URL only. You don't get much more "granular" than that, 
unless I missed something?

> But let's be paranoid, and say they misconfigure their server, and all
> responses include our header. blam, /my/* is exposed, foreign
> documents can start sending authenticated queries to /my/*, and sniff
> results by crawling the resulting DOM.

It is a valid concern but it takes a seriously misconfigured server, 
and even then it's only worth exploiting if the data you would find 
is really valuable - something like user names and passwords or 
credit card numbers, because the exploit is fairly involved (you must 
know a lot to find the vulnerability in the first place, then write a 
JavaScript that exploits it, then spam a million people to get a fair 
number of commerce.foo.com 's customers to go to your exploit page.)

There is a certain barrier to entry when using a HTTP header that 
hopefully would exclude people who don't understand what they are 
doing :-) and I think a header that probably usually would be printed 
out by the script handling requests to that specific URL and thus may 
be more difficult to misconfigure than for the example the 
complicated Mozilla-model document..

> 1) disable cookies for a ContextAgnosticHttpRequest
> 2) maintain an entirely separate cookie table for this request. the
> question then becomes, do we maintain a separate cookie table for each
> referring document? We'd essentially be considering each referring
> document to be a separate application through which a user would
> re-establish credentials to communicate with a foreign site. sounds
> rather painful.

Yes, sounds like that would really complicate browser cookie 
handling. A third way would be to discard previous cookies and not 
send any with the first request, but keep and send any cookies during 
subsequent http communication.

I still think that though misconfiguration can have serious exploit 
potential it would not be a severe problem in real life. Perhaps 
other list members can step in and comment on whether that's too 
optimistic?
-- 
Hallvord Reiar Michaelsen Steen
http://www.hallvord.com/

Note: mail to hallvors at online.no will still be read but you may want to start using 
hallvord at hallvord.com instead