Slashdot Mirror
Busting, and Fixing, Frame Busting
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."
Put yo'self to the test...unless you jest.
Living With a Nerd
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?
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.
... it doesn't even display their website without Javascript.
Just a blank page. Top-notch software engineering work :D
They want their frames back.
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.
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.
...and it works.
The caching technique described in update two coupled with update three of this: Anti-anti-frame busting article works for all cases that I've found when someone is wrapping your site.
The site I develop for is in the financial services industry. It is a big no-no of our clients to do this, but they still seem to wrap their site with a frame at the top which includes their logo.
After seeing some complaints from Jeff Atwood on www.stackoverflow.com (specifically this post: www.stackoverflow.com) I found the article in question.
html f v i s i b i l i t y : hidden ; g
i f ( s e l f == top ) f document . documentElement . s t y l e . v i s i b i l i t y = ' v i s i b l e ' ;
el se f top . l o c a t i o n = s e l f . l o c a t i o n ;
Unless I'm mistaken, isn't there an HTTP header that will prevent this with a compliant browser? Therefore not reliant on the scripts in the framed or parent page. It seems to me that it would be the proper method.
Why don't browser vendors just update (i)frames to same-origin rather than cross-origin?
The only uses of linking 3rd party sites are stupid advertising systems and site hijackers. (in the sense of a parent site iframing others work and making it look as if it was their own, mainly being for the sake of ads again)
Bham. Solved a huge problem in one update.
There are very few cases where sites will frame a 3rd party site with permission.
There are legitimate uses for (i)frames, but ever since the overly-annoying XHRs (XMLHTTPREQUEST) came around, they have fallen in to the low priority stack.
XHRs are plain fucking awful to work with, to put it nicely. And this is simply due to the awful way you have to go about setting them up to work in the first place!
Oh, and let us not forget the fact that JS itself can't even deal with it correctly! XHR is still a HACK. Yes, i went there, bold and caps since it is a point that people hate to admit.
Then we look at frames, it is as simple as setting targets and making anchors. It creates logical separation in a webpage. It is easy to setup. It is syntactically meaningful.
Let's not forget, the guys "in control", the W3C felt the need to KILL the <menu> element in favor of a hack-up of unrelated elements (A LIST IS NOT A MENU!) as well.
Great idea guys! Screw syntactically meaningful HTML, huzzah for anonymous <div>s and <span>s!
At least HTML5 started getting back on the right track, still a long way to fix the horrible mess we are in.
Of course, the whole "separate structure, style and interactivity movement" doesn't like that, despite the fact that CSS3 is filled with interaction, as well as most of HTML...
Screw that. We are meant to be making web development better, not some ass backwards seclusion bullshit. These things are meant to be integrated!
Hell, that's why MathML, SVG, JSON and countless other things exist.
Don't blame HTML for the mess we have, blame the damn implementers of it!
On a slightly related note, the same applies for GOTO, you don't scream at your computer for GOTOing every nanosecond, do you?
Yet people bitch and moan at the slightest mention of GOTO because "IT IS EVIL, IT IS THE COMMAND OF SATAN!"
GOTO is an essential command in any multi-process OS in all the forms it comes in. Whiners need to get back to CLI or admit hypocrisy.
Idiots misuse it, intelligent people use it well.
Watch as i get modded under the bridge.
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.
Search 2010 Gen Con events
Per my subject-line above: How? By doing what today's modern malware can do...
See, everyone (especially around here on this website) touts "JAVA", & from my experiences with it (and yes, other "OOP", or not quite as OOP languages? It's "not all that"...).
Why/how can I say that? Ok, from a security standpoint is how... and because of the difference and abilities drivers have (which rootkits often use).
I state this simply because a LOT of today's "malware in general" is using 'blended threat' technology (which means it uses not only std. means in badly scripted website pages or banner ads, std. Ring 3/usermode executables or scripts, but, also DRIVERS (be they filtering types, Plug N Play (the 'province of Windows' really here as to the name, a not TRULY "kernel mode/ring 0/rpl 0" driver but one that can start/restart while you are INSIDE Windows), or kernel mode/Ring 0/RPL 0 driven drivers).
So, what's the problem here?
Well, since a driver can see ALL MEMORY for any app (including the OS itself)?? What stopping today's modern malwares that use this rootkit type tech from peering inside of an Object-Oriented/OOP program, especially one running in RPL3/Ring 3/Usermode??
NOTHING IS... thus, you can see the obvious advantages driver utilizing malware have, especially for espionage purposes, and yes, even vs. OOP designed code (especially in usermode/Ring 3/RPL 0 CPU privelege level running code, which is, what you as the user, use!)
APK
P.S.=> So much for "OOP" & its PRIVATE or PROTECTED variables + datastructures & objects, eh? It can be "sliced right through", easily, by today's malwares that use rootkit type tech (specifically drivers)... apk
bustaa bustaa BUSTAAAAA
http://seclab.stanford.edu/websec/framebusting/framebust.pdf
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 -- and if you care about old browsers, you could actually write an AJAX framework that gracefully degrades to this. Another example is file uploads -- currently, the best way to upload files is probably (unfortunately) Flash, with its ability to upload multiple files from a single browse dialog. The second-best way is what GMail currently does -- you click an iFrame'd "browse" button, select your file, and after some delay (in case you grabbed the wrong file), it'll auto-submit that iframe, in the background. Smarter uploaders even give you a progress bar, allowing you to upload multiple files at once and watch their progress, all without leaving the page.
But most importantly... I said something good about Flash, so here's the obligatory rant: Flash is currently used for, among other things, "widgets". A year or two ago, I was working on a music widget site. The widget itself started out being pure HTML, using Flash only to play the audio, and I was planning to replace the Flash with an HTML5 audio tag. By the time I left, we had a pure-Flash version of the widget, so that anyone, on any page, even restrictive MySpace pages, could simply embed it -- apparently, Flash makes it easy to embed untrusted widgets (like the YouTube player, for instance) into your site.
The only reasonable alternative to that, if you want actual, interactive widgets, is an iframe. Yes, you could just grab the HTML and inject it into your own page, but then you open yourself up massively (Goatse-style) to cross-site scripting attacks. The only safe way to do that would be to scrub the HTML -- but that would (obviously) mean removing anything resembling a script, and thus, again, you can't have interactive widgets.
Indeed, one of the proposed solutions strikes me as particularly useless -- allow a custom header to deny loading a given page in a frame. Seems like it would be much saner to simply block the technique in question -- it relies on being able to re-style an iframe, scroll it, move it around, etc. In particular, I think only registering clicks on either fully visible iframes or same-domain iframes would solve this, unless I'm missing something?
Don't thank God, thank a doctor!
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.
Don't thank God, thank a doctor!
See my vest
See my vest
Made from real
Gorilla chest...
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 page would at least display? If javascript is disabled, those users shouldn't have to worry about click jacking even if they still get a frame.
Same Origin should prevent the frame from modifying the scripts within it.
"I bust your trace buster buster"
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.
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 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 be for the core - the system clock, time-slicing, etc. ring 1 for system processes, ring 2 could be for I/O (drivers), and ring 3 for userland. This way, system processes can verify the integrity of drivers.
Of course, r00ting a system is still an issue, but only at boot time.
...do you not understand the point of private variables? It's to prevent other other objects from tampering with things inside this object that are liable to be changed in the future or any number of other reasons. It's nothing at all to do with application security.