Posted
by
kdawson
on Tuesday May 25, 2010 @01:55PM
from the don't-frame-me-bro dept.

An anonymous reader writes "A study presented last week at the IEEE Web Security and Privacy workshop shows that frame busting code used at popular websites is easily circumvented. Frame busting is a widely used technique to prevent clickjacking attacks. The researchers propose better frame busting code and suggest that websites migrate to this new code."

Remove Frames altogether. I honestly can't think of a time where a frame has made anything on the web easier save for Kingdom of Loathing.

Even the Google Image searches - its annoying that I have to click on the image and then click on another one to get linked to the full size image. Why not just make the image go straight to the image link, and put a URL under the image that goes to the page its hosted on. No more frames, and less hassle.

Frames constantly break websites, cause vulnerabilities, and have been a nuisance since the 90's.

Nope. Jquery isn't magic, it still follows the same rules under the hood, it is still using xmlhttprequest. The exception to the same origin policy for javascript code is you can load.js files from wherever, so the way around it is jsonp. See for example http://ecmanaut.blogspot.com/2006/01/jsonp-why-how.html [blogspot.com]

The issue here is someone else putting a frame around your page, e.g. to track traffic, or to add a toolbar at the top (e.g. "share this page with your contacts at Facebook/Digg/whatever"), or to clickjack (read that FA for an explanation), or probably other things.

I know. I tried hosting a website back around 2002, I was about 14 so I didn't have total knowledge of how it all worked but I wanted to see if I could successfully run something online with the money I'd saved from a minimum wage job.

I had it going for a solid 9 months, before some jerk opened my web site from a frame, executed some bad code and crashed my server. Fix it all up but for whatever reason he'd keep attacking it. Having school to deal with, I didn't put forth the effort to fight back or put sec

I had it going for a solid 9 months, before some jerk opened my web site from a frame, executed some bad code and crashed my server. Fix it all up but for whatever reason he'd keep attacking it. Having school to deal with, I didn't put forth the effort to fight back or put security around it, so I stopped hosting it.

The fault is not the frame. The fault is our by allowing some arbitrary code to crash your server. You was 14 at the time and making mistakes is normal. But the fault is not on the HTML spec, but solely on your bad coding.

I had it going for a solid 9 months, before some jerk opened my web site from a frame, executed some bad code and crashed my server.

Um, a frame crashed your *server*? That would be a real feat, considering the frame is rendered on the client side, and not touched on the server side at all.
Awww, you're 22 now, how cute. Now get off my lawn.....

Someone loading a frame on their client side by opening their own website and redirecting their main page to your page allows them to execute code in their frame (if they write code in their frame) to be executed by your server.

This is why people wrote scripts to disable people from framing your website in the first place. Don't act all high and mighty that you're older if you don't understand what we're talking about. Go back to bed Gramps

There is almost no way you can really avoid that. Ultimately, once you publish data in a standard format, it is out there. That means that anyone can extract the data and re-present it, embed it in some other content, or indeed do whatever else they feel like.

If a site wants to deep-link and regurgitate badly enough, it's quite capable of running through the entire target site, locally caching the results, and embedding the cached version. This bypasses all protections, but would only work with content that

BAH! Until you start navigating in the sub-frame, then two or three clicks into it decide, "You know, that frame is really annoying. I'd like to turn it off," so you click "remove frame" and BAM! you're magically taken three page views back in time and have to retrace your goddamned steps.

The only place where I have seen frames used to good effect is Javadoc and similar API documentation. Using frames, you get a convenient index of the classes on the left, and can scroll that list independently of the main API docs.

It's worth noting that Javadoc (when generated by Sun's standard doclet) provides a "No Frames" version as a link on every single page. I interpret this as the Java team's acknowledging that frames are so unpleasant that even in the rare case where they're used well, many people can't stand them.

I found exactly one use, one time, back when I was running my Quake site. And the use was, in fact, a joke.

A fellow named "Dopey Smurf" (who is now a medical doctor in Canada IINM) had his Quake site, which he was going to shut down. Being a medical student he had dealings with lab rats, which often bit him.

I had the idea of rather than just having him shut his site down, I'd send him a collection of invisible, website eating lab rats, and he would post a link "FOR GOD'S SAKE DON'T CLICK THIS LINK OR THEY'L

Why don't browser vendors just update (i)frames to same-origin rather than cross-origin?

Because it'd break HTML-only widgets. Example: embedded YouTube videos. Right now, you embed a Flash file, but in the future, they could conceivably use iFrames.

There are legitimate uses for (i)frames, but ever since the overly-annoying XHRs (XMLHTTPREQUEST) came around...

Nope, XHR can't provide the above without introducing cross-site scripting vulnerabilities, or requiring you to trust every single widget producer. I think Facebook allows third-party apps to plug in in a similar fashion, and I doubt you could get Facebook itself to trust Farmville etc.

Frames have their uses. Most browsers generally have better accessibility for frames than for scrollable divs. Most clearly: Open a frames-based page and press Page Down. The primary frame will page down. Open a scrollable-divs-based page and press Page Down. Nothing will happen. Panning (scrolling using the middle mouse button) is also rather hit-or-miss with scrollable divs.

Frames are also a way to hack back/forward button functionality into an Ajax app, and to handle other browser features like file uplo

Personally, I think the best solution that would allow all the use-cases I mentioned (most of which are hacks to get around flaws in browsers' Ajax implementations) would be to allow only pages that have been specifically declared to be frame-able to be put in frames.

Well, remember the news corps they are bitching about google 'stealing' their news because everybody is justreading the news at news.google.com ? If you can view the images directly on google without having to visit thepage, it's bound to get the same sort of reaction: 'google is stealing our images'...

Frames are useful for at least two reasons. One is ajaxupload [valums.com]. They are used to implemented the cool feature in which a user uploads a file along with a progress bar without leaving the page. Number two is to ajax post data to an external domain [nathanm.com]. I believe facebooks like button is implemented using an iframe too. It is a really cool and versatile element, but yes plagued with security problems.

A great example of how frames do their job better than anything that has come along since. Best part is you can download it all to your local computer. So before anyone says "they could put it in a wiki", yes they could, but then the user has to be connected to the net.

It *is* static html and css. You can download it and view it directly off your local file system - no server or internet connection needed. They generate the pages once, then put them on the server, the same as I generate many of the unjava header files using a perl script. It makes it a lot easier to change a class name in one place and have it propagate through much of the source.

Yeah, but you need to run the wiki software on your machine (or download a static set of pages that will have a lot of non-working links that you have to clean up - after all, you can't "edit" the page, and the random page link has to be replaced with some big horking javascript that has a list of all pages), unlike static html framesets.

or download a static set of pages that will have a lot of non-working links that you have to clean up

after all, you can't "edit" the page,

So what? You're talking about developer documentation, and I'm sure a developer could figure that out.

and the random page link has to be replaced with some big horking javascript that has a list of all pages),

Was that ever useful? Especially in API docs.

Seems to me that those two changes could be trivially scripted, if someone wanted to make this possible. Also seems like the framesets won't automagically work, unless, of course, you wget -r, or someone provides you the static sources.

My point was, even with a wiki, unless it's doing some pretty crazy AJAX, wget -r is probably enough to get something workable. There'll be broken links, but they'll be to things you didn't need offline anyway.

OTOH, a webserver doesn't have to be that bad. Rubygems installs RDoc documentation by default, and 'gem server' on the commandline will fire up all the webserver you need. (It uses frames by default, but there's no reason it has to.)

Frames constantly break websites, cause vulnerabilities, and have been a nuisance since the 90's.

The framesets used in 90s are pretty much gone now. However, iframes are used in more places than you realize. A lot of the small widget-looking areas on websites are a lot of the times iframes. Check out igoogle, for example.

First, I agree that framesets themselves could go away and be replaced by scrollable divs. But clickjacking doesn't work on traditional framesets anyway, and as someone pointed out, various API docs put them to good use.

Second, there's a few tricks which conceivably could be better supported in other ways, but not all have working replacements. For example, before XMLHttpRequest, a hidden iFrame was the way to make asynchronous background requests from JavaScript -- an

It's possible I'm thinking of a different vulnerability, but some quick reading elsewhere reveals that the only way framebusting scripts can currently work is to be at the top of the page, and to keep the page hidden until they've made sure they're not framed. It's tricky to support JavaScript if you're going to do that.

... hosted on a site that requires you allow Javascript just to read a static-looking page that only provides a summary and a hyperlink to another major malware vector - a PDF file.

They sure appear to use a lot of unnecessary and insecure crap to serve up an article about how everyone else's web designs suck.

From the site:

A research question: this page contains our proposed Javascript frame busting code. This code resists the attacks in the paper, but we cannot guarantee that the page cannot be framed. If you are able to write HTML that frames this page, please send us a link.

The "better" code fails if javascript is disabled. It fails "safe," if "safe" is defined as "completely uselessly." The entire page is hidden with CSS until some javascript runs that reveals it. Using NoScript, possibly to defend against these very attacks? Congrats, the page silently disappears!

The proposed fix is terrible. Regrettably, we're going to need browser makers to extend their browsers to really fix the problem.

With the local in-line script, could you not first use javascript to change the CSS visibility of the page to hidden, then run their check that returns it to visible? Then for users without javascript, the raw pag

It is only an examply of their proposed solution.Instead of the whole site you would only hide elements that are dangerous to click, and show an explanation why they are disabled, with a nice target="_top" link to the same page.

The proposed fix is terrible. Regrettably, we're going to need browser makers to extend their browsers to really fix the problem.

I agree, but I think the task falls to HTML standards (since they gave us <iframe>).Browser makers shouldn't be left to make up disparate solutions to something that could simply be a part of the HTML and/or HTTP standard.

In HTML: <meta allowframing="false">In HTTP: Allow-Framing: false;

A "true" value (default) would allow the resource to be <iframe>d.A "false" value would show an error placeholder or nothing at all (like broken <img>s do).

Its always seemed silly to me that this wasn't in the standards to begin with...

To begin with? Are you serious?

Yep, I'm serious. I'm not sure when exactly the <img> tag was included, but that's when "hot linking" became a problem.

"Hot linking" and "click-jacking" are two sides of the same coin; They're only possible because there's no standard in place to tell the browser, "Don't display this content if the page's host address doesn't match the resource's address."

Instead, we have to do HTTP-REFERER (sic) checking on the server side to prevent "hot linking". Referrer validation is just as broken as TFA's fra

I'm not sure when exactly the tag was included, but that's when "hot linking" became a problem.

For which there was a trivial solution in the form of referer -- but I also remember hotlinking not being a problem for a long time, though it was certainly possible.

"Hot linking" and "click-jacking" are two sides of the same coin; They're only possible because there's no standard in place to tell the browser, "Don't display this content if the page's host address doesn't match the resource's address."

And in 20/20 hindsight, that makes sense and even seems obvious. But when looking at the img tag problem, I wouldn't immediately think, "Maybe one day people will be able to display HTML from another site in something, I think I'll call it a 'frame', and that won't be able to use the referer header, and it could be really bad."

Referrer validation is just as broken as TFA's frame busting JavaScript code since browsers can be configured to disable both JavaScript and the HTTP referrer.

For which there was a trivial solution in the form of referer -- but I also remember hotlinking not being a problem for a long time, though it was certainly possible.

The first time I used the <img> tag I "hot-linked". The origin site contacted me and asked me to stop it (even though I gave attribution and a link back). I apologized and complied immediately. This was an early and frequent problem I encountered from both sides (YMMV) which could have been prevented in successive versions. This was prior to HTML 4.0, 4.01, XHTML 1.0, and HTML 5.

I'm afraid I've miscommunicated as to which standard's "beginning" I found it silly to not have this feature included wit

As for a "trivial" solution (referrer checking): It was actually non trivial for the webmaster who confronted me about the "hot-linking".

If referer-checking was non-trivial, so would any solution you propose, I would think.

Ah, but since shortly after the <img> we've needed a way to inform browsers of cases when the content should or shouldn't be displayed in mixed domain pages,

I think the point I'm trying to make is that it's not always obvious how to generalize something. Again, the obvious and dead-simple solution to hotlinking is referer-checking. It's not as if people were deliberately hotlinking other content at the time. I know that when I first discovered this problem, I noticed that referer-checking existed, so I shrugged and mentally categorized it as a solved problem.

As for a "trivial" solution (referrer checking): It was actually non trivial for the webmaster who confronted me about the "hot-linking".

If referer-checking was non-trivial, so would any solution you propose, I would think.

No solution is trivial to provide & implement.Once standardized my solution would be trivial to use.

Writing a server side script to conditionally (dis)allow content delivery based on HTTP referral data will always be non-trivial. Just because it's common place nowadays, doesn't make it non-trivial (entire sites can go down if done incorrectly).

Adding one HTML tag to an HTML document is trivial.

Changing many documents this way is non trivial -- configuring the server to send the additional HTTP header i

Writing a server side script to conditionally (dis)allow content delivery based on HTTP referral data will always be non-trivial.

What? It's trivial now. Maybe not as much as:

Adding one HTML tag to an HTML document is trivial.

Of course, the solution I've seen proposed -- an HTTP header -- is equally trivial, certainly to embed in HTML documents via the meta tag. Then again, if referer-checking is "non-trivial" for you, I suspect you'd find it similarly challenging to add a header to those images.

Changing many documents this way is non trivial

I shudder to think what happens the day you're presented a truly non-trivial programming task. I mean, really? It's hardly more than search-and-replace.

configuring the server to send the additional HTTP header it relatively trivial in this case, and is simpler / less processor intensive than conditionally disallowing content via referrer.

A simple option for no cross domain frames would really work well. Possible with abilities to provide a white list of domains where framesets can be loaded from, such as Google images. There's already mechanisms to protect against cross domain XMLHTTPRequest, as well as frames and child windows executing code from other domains. I don't see why the user shouldn't be able to disable loading frames from other domains.

I tried the proposed better solution in Firefox 3.6.3 and it did not work for me; with Firefox in safe mode, it did work. I can only conclude that browser themes and/or add-ons breaks the "default invisible" page setting in the suggested solution.