Busting, and Fixing, Frame Busting 111
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."
Better Yet (Score:5, Insightful)
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.
Anybody here have anything to say in the defense of frames?
Re:Better Yet (Score:5, Funny)
They're great for holding paintings?
Re: (Score:2)
Yeah, but when the inevitable thieves steal the paintings, they almost always damage them when cutting them out. What you really want is a graviton projector embedded in the wall.
Re: (Score:2)
Agreed, frames are the scourge of the web, obliterate them from the universe immediately.
Whereas a DIV that floats annoyingly around your page with content loaded from an external source is perfectly okay, because it's ... ? In the HTML spec ?
Same Origin Policy (Score:5, Informative)
Agreed, frames are the scourge of the web, obliterate them from the universe immediately.
Whereas a DIV that floats annoyingly around your page with content loaded from an external source is perfectly okay, because it's ... ? In the HTML spec ?
Unlike frames, the XMLHttpRequest to get the content into the DIV is restricted by the Same Origin Policy.
Re: (Score:2)
Re: (Score:1)
Unlike frames, the XMLHttpRequest to get the content into the DIV is restricted by the Same Origin Policy.
This could be bypassed as far back as 2008 using jQuery.
http://frinity.blogspot.com/2008/06/load-remote-content-into-div-element.html [blogspot.com]
Re: (Score:1)
Re: (Score:3, Informative)
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]
Re: (Score:2, Insightful)
Right. Frames are annoying, so we say 'hasta la vista' to them. DIVs are equally annoying, buh-bye. JavaScript, Flash, animated GIFs, all annoying, gone. Java applets -- damned annoying. Hey, by the time we're done, we'll all be running lynx!
Re: (Score:2)
And this would be a bad thing, how?
Re: (Score:2)
And this would be a bad thing, how?
I couldn't play pacman at work and call it "research into web development trends".
Re: (Score:2)
I block everything on that list (well, except frames because nobody uses them and I'm not sure how you'd do it anyways, and DIVs of course) and browsing IS much nicer.
Years ago I thought I'd never have javascript default to on because everything it was used for was bad for me, the user, except where the site specifically required these abilities.
Now, more and more sites are realizing that they really need to fallback to text mode cleanly to reach huge segments of the market so they're getting more usable wi
Re: (Score:2)
It's more easily CSSed away, so yes, exactly. That it floats annoyingly is still an abomination worthy of Star Trek 2's ear-bugs.
Re: (Score:2)
Gotta love Firefox addons [mozilla.org] :).
And it's ironic that someone complains about floating bars of fail on Slashdot of all places. Or is it intentional, to encourage people to setup accounts, because you can turn it off then?
Re: (Score:2)
I guess that's what I mean. That thing used to be annoying, now I've forgotten it existed and am using JS on here.
Funny how that works.
I hadn't seen Nuke Anything, I use Aardvark [mozilla.org] for that sort of thing.
Re:Better Yet (Score:4, Insightful)
Re: (Score:2, Redundant)
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
Re: (Score:2, Insightful)
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.
Re: (Score:1)
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.....
Re: (Score:2)
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
Re: (Score:2, Insightful)
Re: (Score:2)
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
Re: (Score:2)
You could try adding one of these one-liners to an interesting-sounding link ...
<?php header("location:http://goatse.fr");
or
<?php header("location:ftp://langley.nsa.gov/secure/briefings/2010/Anti-Terrorist%20Hit%20List.doc")
Let the men in black vans "take care" of the problem.
Re: (Score:3, Insightful)
Google Images uses frames in a useful fashion, imo.
Re: (Score:2)
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.
That is some annoying fucking shit right there.
Re: (Score:1, Informative)
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.
Viola! [userscripts.org]
Re: (Score:2)
Who is Viola?
Re: (Score:2)
Cello!
Re: (Score:2)
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.
For example, check out: the JDK API [sun.com]
However, if you are referring to cross-site frames, I completely agree with you (and am grateful for Firefox's 'show only this frame' function).
Re: (Score:2)
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.
ERROR: HOTLINKING FORBIDDEN (Score:3, Informative)
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.
ERROR: HOTLINKING FORBIDDEN is why. At least loading the original page gives the browser a chance to load and cache the image on the page so that the first hit to the server has an acceptable Referer.
Re: (Score:2)
Re: (Score:2)
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
Re: (Score:2)
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.
XHRs are plain fucking awful to work with, to put it nicely.
So is raw HTTP, if you do it right. That's why sane people use a
Re: (Score:2)
Anybody here have anything to say in the defense of frames?
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
Re: (Score:1)
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.
Exactly. Can anyone think of a reason this would not work?
Re: (Score:2)
Re: (Score:1)
Well, remember the news corps they are bitching about google 'stealing' their news because everybody is just
reading the news at news.google.com ? If you can view the images directly on google without having to visit the
page, it's bound to get the same sort of reaction: 'google is stealing our images'...
Re: (Score:2)
Gmail.
Re: (Score:2)
Re: (Score:2)
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.
Re: (Score:2)
Re: (Score:2)
I was just showing that frames have their uses - not that Java is great. To the contrary, I think Java has major suckage:
I wouldn't be working on unjava [unjava.org] if I thought otherwise.
As for the driver issue - that's stupidity on the part of developers. The cpu provides 4 levels of privilege, and everyone decided to go all binary - ring 0 or ring 3. Ring 0 should
Re: (Score:2)
What, and wikis can't be downloaded?
Re: (Score:2)
Re: (Score:2)
Yeah, but you need to run the wiki software on your machine
Not really...
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.
Re: (Score:2)
They make it available a the bottom of this page [sun.com]. And the framesets work just fine without needing a web server - just open up docs/api/index.html wherever you untarred the files.
It only makes sense, since they have the source for the documentation.
Re: (Score:2)
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.)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Yes, that is what I meant, lol.
Re: (Score:2)
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.
Re: (Score:1)
That kills widgets. (Score:2)
So, people have mentioned a few things.
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
Re: (Score:2)
As far as I know, modern XHTML (<1.1) has no notion of frames anymore. And I doubt they will undo that with version 5.
Also, as far as I know, the only alternative (object tags) don’t work across domains.
Re: (Score:2)
>Anybody here have anything to say in the defense of frames?
There are reasons why, sometimes, it's just not possible to load content with the functionality desired within the same window.
For example, right now I'm working on a project that requires me to query another server for a header that contains user-specific elements, such as message counts, user-specific links, etc.
Unfortunately, we're utilizing a fairly inflexible partner-provided API for the basic infrastructure of the site, but a branded header from a third party. Due to restrictions of the partner's API
Hmm ... (Score:2)
A "study" that determines that disabling Javascript will not allow you to execute Javascript.
I wish *I* could get paid obscene amounts of money to make "studies" like these.
Re:Hmm ... (Score:4, Informative)
... 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.
Re: (Score:2)
Seriously.. what kind of web security lab forces users to enable javascript to view content?
IMO, this site gives Stanford security researchers a bad image.
The countermeasure requires that. (Score:2)
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.
Re: (Score:2)
erm, whoops, this is what preview is for...
I meant, it's tricky to support noscript if you're going to do that. Possible (I think?), but tricky.
Re: (Score:1)
... 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.
I like their approach. Good point on the pdf though.
Re: (Score:2)
A "study" that determines that disabling Javascript will not allow you to execute Javascript.
A study that shows that many high-profile websites (which follow the previous best practices) are insecure because they don't take this into account, and proposes enhanced defense mechanisms.
I wish *I* could get paid obscene amounts of money to make "studies" like these.
If you can repeatedly find security flaws in web best practices, you're welcome to come join the lab. It pays about $15/hr, plus half your health insurance.
Disclaimer: I work with these guys.
Their new code is so secure ... (Score:2, Funny)
... it doesn't even display their website without Javascript.
Just a blank page. Top-notch software engineering work :D
Re: (Score:2)
This is probably more like it:
if(top.location != self.location)
{
window.onbeforeunload = function () {};
window.__defineSetter__('location', function(val) { window.location = val });
top.location = self.location;
}
1995 called (Score:1, Insightful)
They want their frames back.
Re: (Score:2)
isn't there an HTTP header that will prevent this
I got nuthin [google.com]
Re: (Score:2)
X-FRAME-OPTIONS. Supported in virtually every browser nowadays.
Re: (Score:2)
Not all browsers support this, and those that do only do so very recently.
"Better" code fails if javascript is disabled (Score:3, Insightful)
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.
Would it work better with a code change? (Score:2)
This is their code, simply s/[/</g and s/]/>/g
[!-- Experimental framebusting code --]
[style] html { visibility : hidden;} [/style]
[script]
if (self == top) { document.documentElement.style.visibility = "visible"; }
else { top.location = self.location; }
[/script]
[!-- End framebusting code --]
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
Re: (Score:1)
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.
Re: (Score:1)
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).
In any event, you are correct; Web browsers
Re: (Score:2)
Its always seemed silly to me that this wasn't in the standards to begin with...
To begin with? Are you serious?
I mean, "clickjacking" is something which was invented, long after iframes were invented, and iframes weren't in the standard to begin with.
Re: (Score:1)
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
Re: (Score:2)
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.
...WTF?
Browsers c
Re: (Score:1)
when ... the <img> tag was included ... "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.
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
Re: (Score:2)
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.
In other words, it
Re: (Score:1)
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
Re: (Score:2)
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.
Granted, adding a static header is relat
Re: (Score:2)
The browser makers already have. Microsoft led first, and everyone else thought it was a great idea (X-FRAME-OPTIONS HTTP header to tell browsers whether the page allows framing) and implemented it. Well, Microsoft, Apple and Google implemented it.
Re: (Score:2)
URL to pdf (Score:1)
http://seclab.stanford.edu/websec/framebusting/framebust.pdf
No one gunna say it... ? (Score:1)
Doesn't always work in Firefox (Score:1)
Re: (Score:2)
Put yo'self to the test...unless you jest.