W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2009

Re: [cors] Possible need for a "Destination" Header

From: Bil Corry <bil@corry.biz>
Date: Tue, 17 Feb 2009 07:22:42 -0600
Message-ID: <499ABA22.1000507@corry.biz>
To: "Mike Chack (mchack)" <mchack@cisco.com>
CC: public-webapps@w3.org
Mike Chack (mchack) wrote on 2/16/2009 9:25 AM: 
> Unless I am missing something, there seems to be a security hole with
> the current proposal. If a site has been hacked then malicous code can
> send content to any site that abides by the access control policies.  It
> is up to the destination site to accept the request, and in the case of
> a nefarious destination, would most certainly do so. Wouldn't it also
> make sense to have some policy control from the origination site that
> would limit where requests could be made. This could be done in the form
> of a "Desitnation" Header that would give more control over where
> XmlHttp requests could be directed. 

If a site has been compromised, then presumably attackers can set any response header that they want.  One possible solution to this is ABE, from Giorgio Maone of NoScript fame:

	http://hackademix.net/2008/12/20/introducing-abe/

It's essentially a "firewall" for browsers, where the browser wouldn't send on information to an untrusted third-party site unless it was allowed in the ruleset.   Now, Giorgio envisions rules would come from three sources: the user, the community and the site itself.  So even in this case, depending on how he implements it, it could be the compromised site sends new, more relaxed rules, then can send data on to an untrusted third-party site.

Of course, even if ABE successfully prevents the outbound data, it is entirely possible the compromised server could send the data via a back channel (server-to-server, email, etc).  It just depends on the level of compromise we're talking about.


- Bil
Received on Tuesday, 17 February 2009 13:23:23 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:30 GMT