Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
Security The Internet IT

Busting, and Fixing, Frame Busting 111

Posted by kdawson
from the don't-frame-me-bro dept.
An anonymous reader writes "A study presented last week at the IEEE Web Security and Privacy workshop shows that frame busting code used at popular websites is easily circumvented. Frame busting is a widely used technique to prevent clickjacking attacks. The researchers propose better frame busting code and suggest that websites migrate to this new code."
This discussion has been archived. No new comments can be posted.

Busting, and Fixing, Frame Busting

Comments Filter:
  • Better Yet (Score:5, Insightful)

    by Monkeedude1212 (1560403) on Tuesday May 25, 2010 @02:03PM (#32339906) Journal

    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?

    • by Yvan256 (722131) on Tuesday May 25, 2010 @02:08PM (#32339954) Homepage Journal

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

      They're great for holding paintings?

      • by jd (1658)

        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.

    • by daveime (1253762)

      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)

        by tepples (727027) <tepples@[ ]il.com ['gma' in gap]> on Tuesday May 25, 2010 @02:17PM (#32340074) Homepage Journal

        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, 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!

        • by sconeu (64226)

          And this would be a bad thing, how?

          • by jbezorg (1263978)

            And this would be a bad thing, how?

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

        • by WNight (23683)

          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

      • by WNight (23683)

        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.

        • by ultranova (717540)

          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?

          • by WNight (23683)

            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)

      by emurphy42 (631808) on Tuesday May 25, 2010 @02:09PM (#32339974) Homepage
      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: (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)

          by Anonymous Coward

          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.

        • by soppsa (1797376)

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

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

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

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

            • Re: (Score:2, Insightful)

              by riegel (980896)
              Can you say that a bit slower I am missing how/what happened that someone could execute code on your server using frames.
      • by jd (1658)

        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

        • by tomhudson (43916)

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

        by The MAZZTer (911996)

        Google Images uses frames in a useful fashion, imo.

        • 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)

      by Anonymous Coward

      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]

    • by surmak (1238244)

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

      • by VGR (467274)

        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.

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

    • by mcgrew (92797) *

      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

    • by Zarel (900479)

      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

      • by riegel (980896)

        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?

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

    • Gmail.

    • by bjourne (1034822)
      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.
    • by tomhudson (43916)
      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.

      • What, and wikis can't be downloaded?

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

            • by tomhudson (43916)

              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.

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

    • by eples (239989)
      Right, but whether or not your website uses frames, someone else can put yours in one and then do nefarious thing like record keystrokes.
    • by unix1 (1667411)

      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.

    • >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]
    • 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

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

    • by ezraekman (650090)

      >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

  • 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)

      by natehoy (1608657) on Tuesday May 25, 2010 @02:44PM (#32340342) Journal

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

      • by teridon (139550)

        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.

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

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

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

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

  • by Anonymous Coward

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

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

    • by coolgeek (140561)

      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)

    by Anonymous Coward

    They want their frames back.

  • by ChaosDiscord (4913) * on Tuesday May 25, 2010 @02:58PM (#32340482) Homepage Journal

    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.

    • by Rigrig (922033)

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

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

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

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

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

      In any event, you are correct; Web browsers

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

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

          To begin with? Are you serious?

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

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

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

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

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

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

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

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

            ...WTF?

            Browsers c

            • 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

              • 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

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

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

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

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

                  Adding one HTML tag to an HTML document is trivial.

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

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

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

                    Adding one HTML tag to an HTML document is trivial.

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

                    Changing many documents this way is non trivial

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

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

                    Granted, adding a static header is relat

    • by Kalriath (849904)

      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.

    • by CastrTroy (595695)
      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.
  • http://seclab.stanford.edu/websec/framebusting/framebust.pdf

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

Are you having fun yet?

Working...