>The exploit allows an attacker to use any JavaScript-enabled web >browser behind a firewall to retrive content from (HTTP GET) and >interact with (HTTP <form/> POST) any HTTP server behind the >firewall. If the client in use is Microsoft Internet Explorer 5.0+, >Mozilla, or Netscape 6.2+, the attacker can also make calls to SOAP or >XML-RPC web services deployed behind the firewall. It is important to note that this vulnerability is not limited to firewalled servers. Using this vulnerability, a malicious webmaster may include content from other sites in his page and freely interact with their content. The privacy risk for users in this case is quite low because cookies are not transferred to the server (different hostname). But this circumvention of the Same Origin Policy will allow the webmaster to "safely" guess passwords and steal services without any trace (if the "Host" header isn't checked, of course). For example, assume "victim.com" supplies stock market quotes to all connecting clients. "attacker.com" would like to supply this service too. The most common thing for "attacker.com" to do in this case is set up a proxy, and upon a client request at "attacker.com", the server forwards the request to "victim.com", analyzes the response and returns it to the client at "attacker.com" in its own format. This service stealing scenario can be easily noticed and traced by "victim.com", which would simply disallow "attacker.com"'s connection. Indeed, "attacker.com" can use a neutral open proxy, or even multiple proxies in random order, but they are all likely to get blocked at some point if "attacker.com" has heavy traffic. With this vulnerability "attacker.com" can steal services from "victim.com" without them ever knowing it. To "victim.com" it would seem like a real client connected and used their services. While what really happened is the following: * "biz.attacker.com" got pointed at "victim.com"'s IP address. * "fetch.biz.attacker.com" points to the attacker's own web server. * A client requested a quote from "attacker.com". * "fetch.biz.attacker.com" used a hidden iframe to load "biz.attacker.com". * "fetch.biz.attacker.com" set document.domain to "biz.attacker.com". * "fetch.biz.attacker.com" was now able to interact with "victim.com". * "fetch.biz.attacker.com" extracted the results and displayed them. This scenario makes "attacker.com" require virtually no resources in order to serve clients because all the heavy HTTP requests are done by the connecting client to "victim.com", fooling "victim.com" to think they have an actual user and freeing up "attacker.com". A lot of other similar scenarios are exposed by this vulnerability, hopefully Microsoft will fix document.domain so it's required by both sides for cross-hostname interaction. - GMS
