FrameBusting script

Question

It is commonly known that loading your site inside a frame on another site, can potentially expose your site to all kinds of ills, and in general is not a good idea if you have any sensitive data to protect.
Thus, the FrameBusting scripts came about, typically a simple script that runs as the site is loading; if its in a frame it reloads itself without frames.
Usually something simple along these lines:

if (top != self) 
    top.location.replace(location);

Now, if you're on a public site, such as forum, or social networking site, where it is common to post links, and have them displayed in a frame, you might want to framebust your site (if you have anything sensitive there, are have users login, etc), out of the social networking's frames. But you also don't want to disrupt the user's experience, and cause them to think the site they're being linked to is suspicious... So you might be tempted to give them a popup to inform them whats going on - but that might just scare them even more....

So - which do you think would be the OVERALL best solution, considering the entirety of context, risks, and consequences, and avoiding "security theater"?

• Leave the site inside a frame
• Framebust silently
• Provide a popup, just to notify the user what is going on
• Provide a popup to the user with the option to cancel

---

P.S. The site was THIS site, and I found this out when posting the site to numerous security-related groups on LinkedIn after the public beta started (why dont you? ;) ), having received soem negative responses... Turns out, SE goes for option 3 - popup with no option to cancel. Crossposted as a bug to meta....

Answer 1

Nice question. FrameBusting is hard to implement correctly and in nearly all cases it is broken due to reasons like browsers incompatibility, bugs, or developers mistakes.

Recently came across on quite similar question here: http://stackoverflow.com/questions/958997/frame-buster-buster-buster-code-needed. Where is said to prompt user with brief explanation of what is going on. Can not disagree, the simpler explanation - better for user understanding, just beware not to miss details touching users privacy. With given details, user has to think on his own what to do not being scared.

And OWASP has good research paper about this topic: http://www.owasp.org/images/0/0e/OWASP_AppSec_Research_2010_Busting_Frame_Busting_by_Rydstedt.pdf

Answer 2

The solution I'd prefer as a user would be: Allow your site to be framed, but make sure malicious sites can do no harm. Don't continue the user's session from another tab if you are in a frame. Consider making the site read-only in this case. If you allow the user to re-login in the frame, display a warning. Of course this is a lot of work to implement for a rare use case, so it might not be practical.

If you really want to bust frames, I'd suggest an unobstrusive solution. Use the regular framebusting code, maybe in conjunction with the X-Frame-Options HTTP header, and provide a highlighted note on the page instead of a popup.

---

A sidenote: The HTML security model relies on the fact that one site cannot do things to other sites. This gives us the same-origin policy. A lot of hacks are based on bypassing this, by injecting code into other sites etc.. Clickjacking is related, but instead of using code to perform a function in the other site, the attacking page tricks the user into clicking somewhere.

Personally, I think the HTML security model, where servers trust the browser to keep scripts confined, is conceptually flawed. I'd prefer a model where code can do almost anything the user can, and instead you'd rely on security tokens instead. Sure, an attacking script could submit a form to delete a post, but without the right session id and password it would be ignored. This would allow much more interesting applications like mashups, client-only content aggregators, etc.. Of course it is too late to switch the web to such a security model now.

I'm writing this to motivate my advice: Even without relying on browser-enforced separation (e.g. framebusting) it's possible to write safe sites where every action is authorized by the user. Don't make your security rely on no-frames, but assume your site is framed, the SOP is compromised and the framing site can push buttons (with or without instrumentalizing the user).