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.
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
isn't there an HTTP header that will prevent this
I got nuthin
If I have been able to see further than others, it is because I bought a pair of binoculars.
http://seclab.stanford.edu/websec/framebusting/framebust.pdf
X-FRAME-OPTIONS. Supported in virtually every browser nowadays.
For a site about things like basic rights, Slashdot users sure do like to censor "dissent".
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!
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 abstraction layers.
XHR is still a HACK.
What about them, specifically, do you find hackish? The only thing I dislike about XHR is the fact that it still forces HTTP, that we can't do real socket programming with web browsers yet.
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.
It is also navigationally a clusterfuck, if you use them as HTML. How do I bookmark where I currently am in the app? By the time you wire in enough JavaScript for me to be able to grab the hashcode, you may as well have used XHR in the first place.
But if you try to use it as an actual replacement for XHR -- for example, by writing a full-blown, rich-client web application, something like, oh, Google Docs -- what happens to navigation? With XHR, it's very clear -- this is something only exposed to the script, it's only meaningful to the back and forward buttons if the script says so. With iframes, how does the browser know whether it's script-only (thus not part of navigation) or something exposed directly as a frame to the user? It can't, so it just ties them to navigation. Now, how do I disable navigation if I'm only using it in my script, say, to ping an RSS feed?
It sounds to me like iframes are much more of a hack than XHR ever was.
Let's not forget, the guys "in control", the W3C felt the need to KILL the element in favor of a hack-up of unrelated elements (A LIST IS NOT A MENU!)
What? Why not?
Screw syntactically meaningful HTML, huzzah for anonymous...
What? Of course you can do syntactically meaningful HTML. You can even build a REST interface on top of that, and then consume that interface with XHR, or anything else you want.
At least HTML5 started getting back on the right track,
Not really. People keep pointing out canvas as a step in precisely the wrong direction, despite its obvious usefulness.
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!"
Wow, you're just ranting about everything today.
No, I don't bitch when my computer JMPs every nanosecond. I also don't bitch when my VM does dozens of mallocs and frees per second. But we've developed higher-level constructs for a reason, and you'd better have a damned good reason for going lower level.
In particular, GOTO is considered harmful not because it magically makes your code go poof, but because it can lead to spaghetti code, and will at least be far less readable the vast majority of the time. If you have a case where GOTO makes sense, you'd better have a damned good explanation, just as you'd better have a damned good explanation for why you rewrote something in assembly, or why you insist on using C in apps for which security i
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!
Not all browsers support this, and those that do only do so very recently.
Don't thank God, thank a doctor!
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.