- From: Hallvord Reiar Michaelsen Steen <hallvord@hallvord.com>
- Date: Tue, 22 Mar 2005 18:42:36 +0100
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
Received on Tuesday, 22 March 2005 09:42:36 UTC