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

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 UTC