We Done Been ... Framed!

@o.s. – Invisible iframes are often necessary in multi-vendor Ajaxian web sites for cross-site scripting… until cross-document messaging takes off, we’re stuck with the late-90’s hidden iframe trick.

@Mark – Let’s see what happens to the web-based economy of the past 8 years if we all turn off JavaScript. Ooh, that’s ugly. Yes Google, but no Google Maps, Gmail, or any of thousands of elegant web applications that make life better. Features that fall under the “Ajax” rubric aren’t just bells and whistles – they’re called “functionality.”

seanb said it best… if security against hacking is your only motivator, use pen and paper.

Finally, @Jeff – good post. Ignore the nay-sayers.

I think that the only one who should be worried is the user. Consider the scenario where someone wants to provide a “Browser in browser” service. Think of it like Digg providing internet browsing through their site having the bar act as a browser window frame. Of course you shouldnt bust it. It is like a “virtual browser” in a browser. If the user doesnt want it or like it, he/she should manually change domain.

URL Shorteners USERS UNITE!

  1. Thou shalt not FRAME my URL.

  2. Thou shalt not display any advertisements during the redirection of my URL.

  3. Thou shalt not promote additional information during the redirection of my URL.

http://www.url360.me/commandments.html

Any pop ups would be more damaging to the innocent site that they would be for the disreputable frame buster busting site…

Therefore, I must agree with this post:

http://beerpla.net/2009/02/12/how-to-fight-clickjacking-using-the-recent-twitter-hijacking-as-an-example/

The solution does not go without having the user be a bit more savvy about browsing. (i.e. paranoid)

As a user, have NoScript or something like it block by default, and make sure you only allow the sites you trust to run any code. A bit troublesome to start with, but it grows on you like a third arm.
(very handy once you get used to it some would say)

This of course would prevent the frame busting code from being busted.

Not even close to being a silver bullet, but unless the user trusts a site he/she shouldn’t trust, the chances of the browsing experience being safe are high.

We should blame the nature of general web browsing on this, the initial thought of having a way to read information online has gone beyond what was supposed to be, we all know this, but still we need it to be more that what it can be, this is why time and again we all think that maybe the answer is moving away from all of that JavaScripting and move towards something less open to so much inteference:

Flash( and/or adobe air, Flex) or Silverlight, WPF to provide any sort of responsible service on the internet, and leave the rest of the web content to just book reading.

Personally I would like to see a world where I don’t have to enable JavaScript to have a good browsing experience.

Ric

I’m not sure why everyone continues to comment after Sicovitol spoke.

Frames aren’t the issue, period. Smart DOM processing means that you can’t prevent what you are trying to prevent. Ever.

@pkchukiss and others suggesting a solution involving detecting being framed, and then serving a page with a “click here to proceed to the content” link – would the framing site (attacker) be able to respond by just positioning their transparent button over your “click here” link?

@Andrew:

What you’re missing is that what other people wrap your site in can affect your reputation and perhaps even land you in legal trouble.

Let’s say your site is maliciously wrapped in an attack and the victimized site user decides to sue your company for failing to take adequate security measures to prevent them from falling prey to the scam. Do you really trust your judicial system to understand that the inherent structure of the web makes this impossible? I can easily see a judge and jury handing down a multi-million dollar tort judgement against an innocent website owner whose only crime was being victimized by a malicious clickjacker.

I writ about my experience from the other side (me trying to frame stack overflow) https://medium.com/@leeleepenkman/running-a-http-proxy-server-at-scale-7a6397dd5dce#.czim1nn6g

I used the iframes sandbox attribute to disable alerts and navigation e.g.
<iframe sandbox="allow-same-origin allow-scripts allow-forms allow-pointer-lock"

The way i framed you was a bit different in that my product has an iframe which is a proxy server which shares the same origin to allow communication between the frames, serve things through
tecnically you could combat that attribute because i used ‘allow-same-origin allow-scripts’ together and i’m running on the same origin so you could actually have a script that looked into the top page and disabled any sandbox attributes on your own iframe (if xorigin allows) and then do your window.locatoin.replace breakout once granting yourself the permissions…

Then i could combat that by locking down the communications by not using the same origin and using postmessage between the frames, which you could probably combat by destroying the functionality of your own page when you detect you have been framed/proxied, i could start to regex strip that destructive code out in my proxy server that serves stackoverflow and yea what a mess.

on the subject of proxies i have seen more malicious annoying ones than my product (WebFiddle) i noticed stackoverfliow .com a spammy stack overflow proxy which adds their own ads, and i guess theres another anti malicious proxy dance which goes on a similar tit for tat style, it would be awesome to hear about how that goes too :smiley: