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
