We Done Been ... Framed!

seems like this is a solution:

http://coderrr.wordpress.com/2009/06/18/anti-anti-frame-busting/

It seems like a local proxy like Proxomitron, which has for many years had built-in functionality to break unbeforeunload handlers, would be a pretty good protection against these kinds of frame-double-busting. The evil framing site can’t prevent your busting if you’ve modified the content before the browser sees it.

@John Davidson

Browsers would still support frames because of all the sites that use it.

I’m assuming that we’re ignoring browsers with Javascript disabled, because the malicious script wouldn’t run. Nor would the frames buster script anyway.

That leaves scripting-enabled browsers. I would blank out the content, or replace everything with a normal message, asking the user to click a link to continue to the content.

Please follow
this link to access the website.

Your actual website opens in a brand new page, the user gets to see what he wants, and the malicious website gets none of the convenience of placing itself on top of your content.

Now, there might be problems with opening new browser windows each time this occurs, but with the new age browsers, these commands to open a new window actually opens a new tab instead. It isn’t the best solution for users of ancient browsers (I’m looking at you, IE6), but as a general precaution, I believe that it’s least disruptive in achieving the desired effect.

Uhhh… Didn’t Hofstadter already mention this class of problem in Gödel,Escher,Bach?

What about instead busting the frame, changing the page to a link that bust the frame?

This should work, shouldn’t?

I agree with bbot - NoScript ( http://noscript.net/ ) and similar client tools are one answer. See the nice discussion on Steve Gibson’s Security Now! podcast: http://www.grc.com/sn/sn-168.htm

Facebook does this now too with all external links

Did they use special effects to insert Antonio Sabato Jr. into the movie too, or just the poster?! PhotoshopDisaster: Perspective Fail

The referenced stackoverflow thread is superior to this one. Sorry. :wink:

A hostile page can prevent your page from even telling whether it is framed or not. The only way to prevent it is to ask your users to take steps like disabling javascript or frames.

Another alternative framing method is using the object tag I don’t know if this is easy to stop or not (i don’t think it is) but I have seen this kind of thing written in asp.net in this case it has a dynamic parameter.

@"“
Oops! That didn’t work…
”;

Sorry it cropped out my code as it had tags in, if you lookup using the object tag instead of iframe there is yet another way of creating frames.

http://www.felgall.com/noiframe.htm

Uhhh… Didn’t Hofstadter already mention this class of problem in Gödel,Escher,Bach?

Yeah, c’mon Jeff. If you’d done your homework first you would have known this and spared us your redundant post. It’s practically lifted from Hofstadter’s 1979 work.

Let’s call it like it is: content stealing, usually shameless. If someone wants to do it, I agree: there is no stopping them.
All the frame talk is just beating around the bush, since it’s fairly simple to simply grab the target content doing a remote read/include, fixing relative references (CSS, scripts, links etc.), stripping scripts (including inline) and do all related processing via smart DOM parsing. This is the cornerstone of any half decent visual screen-scraping engine.
Then output that content into your page, whilst eventually framing your own adjacent content, to preserve your CSS formatting. Sky’s the limit. Unless decency (or the law) have their say.

Sixty-fourth!

Sixty-fourth!

Humm… I can ‘frame bust’ just fine in Opera. No javascript needed.

@Mark

Safer again to just unplug the intertubes and read a book, makes XSS and clickjacking impossible.

For that matter, don’t drive a car, and well, toasters can kill you too…

However, here in 2009, for most websites, clients want convenience features and bells and whistles that can only be accomplished with client side scripting - “… you know, just like how Gmail / Yahoo / Facebook does it …”. They don’t often want to pay for compatibility with the Luddite 5%.

Scripting, which underpins the whole “web x(x=>( x.IsBiggerThanAnyoneElses )).0” thang, just is not going away, the onus is on browser vendors to do a better job of securing it.
(or disable it, but they won’t get much market share if they do that)

Actually, I found out that a growing number of browsers just don’t call the onbeforeunload function (eg. Opera).
One of the reasons is probably to avoid these pesky pop-under ads.
Perhaps what you show is another reason.

I tried that to find out if the user closes the tab/page/browser without unlogging, to unlog him automatically. I found out that there is no reliable and cross-browser way to do that, partly because of above restriction.