When an attacker intercepts a response bound to the victim, an attacker adds an iFrame (which is possibly invisible) to the response referencing some domain with sensitive functionality and forwards the response to the victim. The victim's browser than automatically initiates an unauthorized request to the site with sensitive functionality. The same origin policy would prevent making these requests to a site other than the one from which the Java Script came, but the attacker once again uses active adversary in the middle to intercept these automatic requests and redirect them to the domain / service with sensitive functionality. Any persistent cookies that the victim has in their browser would be used for these unauthorized requests. The attacker thus actively directs the victim to a site with sensitive functionality. When the site with sensitive functionality responds back to the victim's request, an active adversary in the middle attacker intercepts these responses, injects their own malicious Java Script into these responses, and forwards to the victim's browser. In the victim's browser, that Java Script executes under the restrictions of the site with sensitive functionality and can be used to continue to interact with the sensitive site. So an attacker can execute scripts within the victim's browser on any domains the attacker desires. The attacker is able to use this technique to steal cookies from the victim's browser for whatever site the attacker wants. This applies to both persistent cookies and HTTP only cookies (unlike traditional XSS attacks). An attacker is also able to use this technique to steal authentication credentials for sites that only encrypt the login form, but do not require a secure channel for the initial request to get to the page with the login form. Further the attacker is also able to steal any autocompletion information. This attack pattern can also be used to enable session fixation and cache poisoning attacks. Additional attacks can be enabled as well.