Beta

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Busting, and Fixing, Frame Busting

kdawson posted more than 4 years ago | from the don't-frame-me-bro dept.

Security 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."

cancel ×

111 comments

Sorry! There are no comments related to the filter you selected.

Code of the west (-1, Offtopic)

Anonymous Coward | more than 4 years ago | (#32339794)

Frame your bust, fix your vest.

Re:Code of the west (1)

Pojut (1027544) | more than 4 years ago | (#32339866)

Put yo'self to the test...unless you jest.

Re:the actual proposed code. (0)

Anonymous Coward | more than 4 years ago | (#32340340)

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 ;

Re:Code of the west (0)

Anonymous Coward | more than 4 years ago | (#32344236)

See my vest
See my vest
Made from real
Gorilla chest...

Better Yet (5, Insightful)

Monkeedude1212 (1560403) | more than 4 years ago | (#32339906)

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 (5, Funny)

Yvan256 (722131) | more than 4 years ago | (#32339954)

Anybody here have anything to say in the defense of frames?

They're great for holding paintings?

Re:Better Yet (1)

jd (1658) | more than 4 years ago | (#32340040)

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:Better Yet (1)

daveime (1253762) | more than 4 years ago | (#32339960)

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 (4, Informative)

tepples (727027) | more than 4 years ago | (#32340074)

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:Same Origin Policy (1)

aztracker1 (702135) | more than 4 years ago | (#32340648)

JSONP would work with a callback method, or if passed an ID for a div to self-inject into could work, but rarely do you control the foreign resource..

Re:Same Origin Policy (0)

daveime (1253762) | more than 4 years ago | (#32340998)

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:Same Origin Policy (1)

DoubleDownOnEleven (690607) | more than 4 years ago | (#32341318)

The article you posted does not bypass the same origin policy, as mentioned in the comments below the article. The browser will still disallow cross-site attempts.

Re:Same Origin Policy (2, Informative)

eison (56778) | more than 4 years ago | (#32341368)

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:Better Yet (2, Insightful)

morgan_greywolf (835522) | more than 4 years ago | (#32340092)

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:Better Yet (1)

sconeu (64226) | more than 4 years ago | (#32340584)

And this would be a bad thing, how?

Re:Better Yet (0)

Anonymous Coward | more than 4 years ago | (#32340746)

ASCII pRon? No thanks. I shelved my C64 for a reason.

Re:Better Yet (1)

jbezorg (1263978) | more than 4 years ago | (#32341220)

And this would be a bad thing, how?

I couldn't play pacman at work and call it "research into web development trends".

Re:Better Yet (1)

WNight (23683) | more than 4 years ago | (#32342892)

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 without javascript. In giving their users a way to access their content without javascript they've had to stop doing the annoying things or all their customers would have simply chosen the nicer interface. Now for many sites, and more all the time, there's no reason to block any features (except maybe banners) to have a productive browsing experience.

At this rate y'all are almost welcome back on my porch. It's an odd feeling.

Re:Better Yet (1)

WNight (23683) | more than 4 years ago | (#32342786)

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:Better Yet (1)

ultranova (717540) | more than 4 years ago | (#32346064)

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.

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:Better Yet (1)

WNight (23683) | more than 4 years ago | (#32348556)

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 (3, Insightful)

emurphy42 (631808) | more than 4 years ago | (#32339974)

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.

Re:Better Yet (1, Redundant)

Monkeedude1212 (1560403) | more than 4 years ago | (#32340124)

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 security around it, so I stopped hosting it.

I have hated Frames ever since. Surmak mentioned the Java API's, which I admit I do use frequently enough, but even that I keep stored locally.

I don't see anything -WEB BASED- that requires a frame.

Re:Better Yet (2, Insightful)

Anonymous Coward | more than 4 years ago | (#32340236)

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:Better Yet (1)

soppsa (1797376) | more than 4 years ago | (#32346730)

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:Better Yet (1)

Monkeedude1212 (1560403) | more than 4 years ago | (#32348244)

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:Better Yet (2, Insightful)

riegel (980896) | more than 4 years ago | (#32349744)

Can you say that a bit slower I am missing how/what happened that someone could execute code on your server using frames.

Re:Better Yet (1)

jd (1658) | more than 4 years ago | (#32340282)

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 had no controls of any kind beyond straight HTML links. For real-time, just have a spider do all the wandering through the site to the target page. That bypasses any server-side protections automatically, as a "user" is indeed going through all the prior pages - they're just never presented to a human user. I/O is then proxied through the spider, so the remote site sees the spider and treats it as a legitimate user. So long as the spider knows how to get from A to B, when a link on the page does not actually exist, you can simulate the user's navigation. To the user, it's deep-linked. To the target site, it's valid exploration.

It is unnecessary to actually develop such a bot. It is sufficient to show that it is impossible to protect a site against copying, deep-linking, etc, on the server or on the client. If you want to protect content, you cannot do so using the mechanisms in Javascript, HTML or HTTP.

Re:Better Yet (1)

tomhudson (43916) | more than 4 years ago | (#32341504)

It is sufficient to show that it is impossible to protect a site against copying, deep-linking, etc, on the server

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:Better Yet (2, Insightful)

The MAZZTer (911996) | more than 4 years ago | (#32340344)

Google Images uses frames in a useful fashion, imo.

Re:Better Yet (1)

Civil_Disobedient (261825) | more than 4 years ago | (#32343398)

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:Better Yet (1, Informative)

Anonymous Coward | more than 4 years ago | (#32340024)

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:Better Yet (1)

drewhk (1744562) | more than 4 years ago | (#32340206)

Who is Viola?

Re:Better Yet (0)

Anonymous Coward | more than 4 years ago | (#32340310)

It's a small violin made of cheese!

Re:Better Yet (1)

Adrian Lopez (2615) | more than 4 years ago | (#32343002)

Viola!

Cello!

Re:Better Yet (1)

surmak (1238244) | more than 4 years ago | (#32340064)

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:Better Yet (1)

VGR (467274) | more than 4 years ago | (#32342668)

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.

Re:Better Yet (0)

Anonymous Coward | more than 4 years ago | (#32349022)

If you can't stand frames you're a neurotic idiot. If you use their noframes version, you lose the table of contents entirely. It's likely there just for people with browser like Internet Explorer 1.0 that did not support frames.

ERROR: HOTLINKING FORBIDDEN (2, Informative)

tepples (727027) | more than 4 years ago | (#32340068)

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:ERROR: HOTLINKING FORBIDDEN (0)

Anonymous Coward | more than 4 years ago | (#32340744)

https://addons.mozilla.org/en-US/firefox/addon/953/

Re:ERROR: HOTLINKING FORBIDDEN (1)

tepples (727027) | more than 4 years ago | (#32344846)

Google can't ensure that all users of Google Image Search have 1. Firefox and 2. the RefControl add-on.

Re:Better Yet (0)

Anonymous Coward | more than 4 years ago | (#32340184)

I use them on all my websites and only test against IE6.

Re:Better Yet (1)

mcgrew (92797) | more than 4 years ago | (#32340380)

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'LL ESCAPE!!!"

The link was to a framed page I sent him via email that held a page on my own server with an animated GIF of a screenshot of his own page being eaten by the invisible rats.

Uh, it was one of those "you had to be there" things. Lots of fun in the old days, what with Nacho's shambler pissing on the couch, using a BFG as a bong, etc.

Why ditch it when it is better to upgrade it? (0)

Anonymous Coward | more than 4 years ago | (#32340404)

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.

Re:Why ditch it when it is better to upgrade it? (1)

SanityInAnarchy (655584) | more than 4 years ago | (#32343904)

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 is more of a concern than performance.

Idiots misuse it, intelligent people use it well.

No, everyone misuses it -- that's what "bugs" are called. Why would an intelligent person ever use a construct which they're more likely to screw up, unless they had a damned good reason?

Re:Better Yet (1)

Zarel (900479) | more than 4 years ago | (#32340412)

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 uploads, or remembering usernames/passwords that weren't designed with Ajax in mind.

(An astute observer may mention that asynchronous file uploads without iframes are possible with HTML5, but considering that Chrome, Safari, Opera, and IE haven't implemented HTML5 file upload yet, frames are still necessary. HTML5 file upload is also ridiculously complex; iframe uploads are far simpler.)

Someone above also mentioned that frames allows Google Image Search to get around hotlinking restrictions.

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.

Re:Better Yet (1)

riegel (980896) | more than 4 years ago | (#32349876)

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:Better Yet (1)

rev_sanchez (691443) | more than 4 years ago | (#32340512)

I like it when web developers use them as it makes it convenient to ad-block a lot of ads on a site at once. It's possible that isn't what they had in mind.

Re:Better Yet (1)

robinvanleeuwen (1009809) | more than 4 years ago | (#32340580)

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:Better Yet (1)

fulldecent (598482) | more than 4 years ago | (#32340978)

Gmail.

Re:Better Yet (1)

bjourne (1034822) | more than 4 years ago | (#32341116)

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.

Re:Better Yet (1)

tomhudson (43916) | more than 4 years ago | (#32341352)

http://java.sun.com/javase/7/docs/api/ [sun.com]

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:Better Yet (0)

Anonymous Coward | more than 4 years ago | (#32341418)

I love that layout, but it could easily be replicated with static HTML and CSS, albeit at the cost of repeating the navigation structure in each page. If you throw in a little Javascript, much smoother navigation is possible, still with no server interaction.

Re:Better Yet (1)

tomhudson (43916) | more than 4 years ago | (#32350700)

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.

Coming from JAVA? I can "slice thru its OOP", easy (0)

Anonymous Coward | more than 4 years ago | (#32342468)

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

Re:Coming from JAVA? I can "slice thru its OOP", e (1)

tomhudson (43916) | more than 4 years ago | (#32350856)

I was just showing that frames have their uses - not that Java is great. To the contrary, I think Java has major suckage:

  1. no preprocessor
  2. import * crappiness
  3. "everything is a class" causes "too many trees"
  4. single inheritance
  5. overly-verbose (see "everything is a class")

    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 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.

Re:Better Yet (1)

SanityInAnarchy (655584) | more than 4 years ago | (#32343568)

What, and wikis can't be downloaded?

Re:Better Yet (1)

eples (239989) | more than 4 years ago | (#32341400)

Right, but whether or not your website uses frames, someone else can put yours in one and then do nefarious thing like record keystrokes.

Re:Better Yet (1)

eples (239989) | more than 4 years ago | (#32342064)

Wait, I just realized you meant to not support the tag in the browser at all. Okay I agree there.

Re:Better Yet (1)

Monkeedude1212 (1560403) | more than 4 years ago | (#32342364)

Yes, that is what I meant, lol.

Re:Better Yet (1)

unix1 (1667411) | more than 4 years ago | (#32341710)

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:Better Yet (1)

surveyork (1505897) | more than 4 years ago | (#32343744)

>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 Your wish has been answered: OptimizeGoogle https://addons.mozilla.org/en-US/firefox/addon/52498/ [mozilla.org]

That kills widgets. (1)

SanityInAnarchy (655584) | more than 4 years ago | (#32343758)

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?

Re:Better Yet (1)

Hurricane78 (562437) | more than 4 years ago | (#32343796)

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:Better Yet (0)

Anonymous Coward | more than 4 years ago | (#32343852)

Didn't you get the memo? XHTML is dead. HTML5 is where it's at.

Re:Better Yet (0)

Anonymous Coward | more than 4 years ago | (#32349166)

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

Then you're an idiot. How are you going to implement a sidebar menu with dozens of links (Table of Contents) that doesn't reload the whole page (causing you to lose the position within the Table of Contents widnow) if you can't use JavaScript (hello, NoScript clowns, I'm talking about you)?

Implement this without frames and without losing the above advantages:
http://java.sun.com/javase/7/docs/api/ [sun.com]

Re:Better Yet (1)

ezraekman (650090) | more than 4 years ago | (#32349694)

>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, the only server-side include that can be done requires that the connection be made without passing user-specific cookies. (i.e. the server goes and queries the brand's server for the header, but can't pass the user's cookies/credentials over when it does, thus, can only return code in that query that isn't user-specific.) However, due to the aforementioned need that the header support user-specific details, that solution isn't sufficient. The browser would normally provide this via cookies and/or session data, but since it's a server-to-server connection that makes the header request, that isn't possible until the API is changed to support passing browser variables and cookies in the query. So, in the meantime, an iframe will probably be used to bridge the gap. Since it's the browser that's making the request, the user's cookies/session data remains intact when the query is made, so the code returned is user-specific.

Is it ideal? No. Is it the only feasible way to solve the problem until the header is normalized or the partner's API is made more flexible? Yep! We don't live in a laboratory; we live in the real world. Sometimes, we're told to build something and handed a set of tools that isn't the best way to do the job. There isn't always time or flexibility to do it "right", as much as we wish we could convince our bosses (or in this case, partners) to do so. And in those circumstances, I'm glad we at least have the flexibility of frames/iframes to get the job done. I hate using them, but sometimes you're stuck between a deadline and an inflexible API, and there just isn't another option in the time you have.

"I was jes' follerin' orders, boss!"

Hmm ... (1)

daveime (1253762) | more than 4 years ago | (#32339920)

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 ... (3, Informative)

natehoy (1608657) | more than 4 years ago | (#32340342)

... 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:Hmm ... (1)

teridon (139550) | more than 4 years ago | (#32340502)

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. (1)

SanityInAnarchy (655584) | more than 4 years ago | (#32343934)

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:The countermeasure requires that. (1)

SanityInAnarchy (655584) | more than 4 years ago | (#32343942)

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:Hmm ... (1)

greyblack (1148533) | more than 4 years ago | (#32345688)

... 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:Hmm ... (1)

wirelessbuzzers (552513) | more than 4 years ago | (#32343196)

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 ... (2, Funny)

Anonymous Coward | more than 4 years ago | (#32339924)

... it doesn't even display their website without Javascript.

Just a blank page. Top-notch software engineering work :D

Re:Their new code is so secure ... (1)

coolgeek (140561) | more than 4 years ago | (#32342028)

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;
}

Re:Their new code is so secure ... (0)

Anonymous Coward | more than 4 years ago | (#32342294)

This is broken in many ways

1995 called (1, Insightful)

Anonymous Coward | more than 4 years ago | (#32339948)

They want their frames back.

Hello (-1, Offtopic)

Anonymous Coward | more than 4 years ago | (#32340004)

<blink>mojo</blink>

Anti-anti-frame busting code exists... (0)

Anonymous Coward | more than 4 years ago | (#32340292)

...and it works.

The caching technique described in update two coupled with update three of this: Anti-anti-frame busting article [wordpress.com] 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 [stackoverflow.com] ) I found the article in question.

Re:Anti-anti-frame busting code exists... (0)

Anonymous Coward | more than 4 years ago | (#32341946)

I think that the code will still fail to break out of a frameset if the attacker uses variable clobbering to make the involved objects unusable or forbidden. That's why the approach presented in the paper is to be very cautious: Either the code detects that there are no frames or the page is not shown. They don't rely on their framebusting code. If it fails, it fails to a blank page, not to a usable page in a frame.

Why use Javascript at all? (0)

Anonymous Coward | more than 4 years ago | (#32340382)

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.

Re:Why use Javascript at all? (1)

Qzukk (229616) | more than 4 years ago | (#32340996)

isn't there an HTTP header that will prevent this

I got nuthin [google.com]

Re:Why use Javascript at all? (1)

Kalriath (849904) | more than 4 years ago | (#32343404)

X-FRAME-OPTIONS. Supported in virtually every browser nowadays.

Re:Why use Javascript at all? (1)

SanityInAnarchy (655584) | more than 4 years ago | (#32343944)

Not all browsers support this, and those that do only do so very recently.

"Better" code fails if javascript is disabled (2, Insightful)

ChaosDiscord (4913) | more than 4 years ago | (#32340482)

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.

Re:"Better" code fails if javascript is disabled (0)

Anonymous Coward | more than 4 years ago | (#32341364)

That's by design as there is no reliable alternative to Javascript code. The downside to this approach is explained in the paper and mitigation options are presented.

The idea behind that code is that the only path which shows the page is when the code (a) runs and (b) detects that the page is not framed. When the frame busting fails, which it obviously can, then the page is still not shown, because then the only satisfactory path isn't executed. When the attacker prevents the Javascript from running, the code isn't executed at all, so the page stays hidden. This last case is indistinguishable from completely disabled Javascript. That's why the fail blank approach has to be taken for maximal framing protection.

Would it work better with a code change? (1)

nullchar (446050) | more than 4 years ago | (#32345250)

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.

Re:Would it work better with a code change? (0)

Anonymous Coward | more than 4 years ago | (#32345736)

Same origin prevents the other site from changing the script, but not from stopping it. Read the paper. The other site can selectively turn off Javascript for the target site, so to speak. As I wrote before, hiding the page when Javascript is disabled is by design. There is no 100% reliable way of busting out of a frameset without Javascript, especially if caches are involved. Consequently the site has to require Javascript if framing protection is a requirement.

Re:"Better" code fails if javascript is disabled (1)

Rigrig (922033) | more than 4 years ago | (#32341788)

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:"Better" code fails if javascript is disabled (1)

VortexCortex (1117377) | more than 4 years ago | (#32342750)

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 will still need extending.
Its always seemed silly to me that this wasn't in the standards to begin with...

Re:"Better" code fails if javascript is disabled (1)

SanityInAnarchy (655584) | more than 4 years ago | (#32343952)

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:"Better" code fails if javascript is disabled (1)

VortexCortex (1117377) | more than 4 years ago | (#32349532)

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 frame busting JavaScript code since browsers can be configured to disable both JavaScript and the HTTP referrer.

It seems silly to me "hot linking" and "click-jacking" can both be prevented via a simple extension to HTTP and HTML, and yet these problems still exist.

Re:"Better" code fails if javascript is disabled (1)

Kalriath (849904) | more than 4 years ago | (#32344578)

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:"Better" code fails if javascript is disabled (1)

CastrTroy (595695) | more than 4 years ago | (#32347004)

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.

sex with a= Sponge (-1, Redundant)

Anonymous Coward | more than 4 years ago | (#32340954)

on slashd0t.or6 found out about the and arms and dick

Furemu (0)

Anonymous Coward | more than 4 years ago | (#32342484)

bustaa bustaa BUSTAAAAA

URL to pdf (1)

emeade (123253) | more than 4 years ago | (#32343080)

http://seclab.stanford.edu/websec/framebusting/framebust.pdf

No one gunna say it... ? (1)

ToxIk_Waste (1019424) | more than 4 years ago | (#32345408)

"I bust your trace buster buster"

Doesn't always work in Firefox (1)

achowe (829564) | more than 4 years ago | (#32345858)

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.
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?
or Connect with...

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>