<?xml version="1.0" encoding="utf-8"?>
<feed xml:lang="en-us" xmlns="http://www.w3.org/2005/Atom"><title>Simon Willison's Weblog: framebusting</title><link href="http://simonwillison.net/" rel="alternate"/><link href="http://simonwillison.net/tags/framebusting.atom" rel="self"/><id>http://simonwillison.net/</id><updated>2010-05-24T11:40:00+00:00</updated><author><name>Simon Willison</name></author><entry><title>Busting frame busting: a study of clickjacking vulnerabilities at popular sites</title><link href="https://simonwillison.net/2010/May/24/busting/#atom-tag" rel="alternate"/><published>2010-05-24T11:40:00+00:00</published><updated>2010-05-24T11:40:00+00:00</updated><id>https://simonwillison.net/2010/May/24/busting/#atom-tag</id><summary type="html">
    
&lt;p&gt;&lt;strong&gt;&lt;a href="http://seclab.stanford.edu/websec/framebusting/"&gt;Busting frame busting: a study of clickjacking vulnerabilities at popular sites&lt;/a&gt;&lt;/strong&gt;&lt;/p&gt;
Fascinating and highly readable security paper from the Stanford Web Security Research group. Clickjacking can be mitigated using framebusting techniques, but it turns out that almost all of those techniques can be broken in various ways. Fun examples include double-nesting iframes so that the framebusting script overwrites the top-level frame rather than the whole window, and a devious attack against the IE and Chrome XSS filters which tricks them in to deleting the framebusting JavaScript by reflecting portions of it in the framed page’s URL. The authors suggest a new framebusting snippet that should be more effective, but sadly it relies on blanking out the whole page in CSS and making it visible again in JavaScript, making it inaccessible to browsers with JavaScript disabled.

    &lt;p&gt;&lt;small&gt;&lt;/small&gt;Via &lt;a href="http://delicious.com/jdunck/clickjacking+iframe"&gt;Jeremy Dunck&lt;/a&gt;&lt;/small&gt;&lt;/p&gt;


    &lt;p&gt;Tags: &lt;a href="https://simonwillison.net/tags/clickjacking"&gt;clickjacking&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/framebusting"&gt;framebusting&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/iframes"&gt;iframes&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/javascript"&gt;javascript&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/security"&gt;security&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/xss"&gt;xss&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/recovered"&gt;recovered&lt;/a&gt;&lt;/p&gt;



</summary><category term="clickjacking"/><category term="framebusting"/><category term="iframes"/><category term="javascript"/><category term="security"/><category term="xss"/><category term="recovered"/></entry><entry><title>The Dangers of Clickjacking with Facebook</title><link href="https://simonwillison.net/2009/Dec/23/clickjacking/#atom-tag" rel="alternate"/><published>2009-12-23T10:20:43+00:00</published><updated>2009-12-23T10:20:43+00:00</updated><id>https://simonwillison.net/2009/Dec/23/clickjacking/#atom-tag</id><summary type="html">
    
&lt;p&gt;&lt;strong&gt;&lt;a href="http://theharmonyguy.com/2009/10/14/the-dangers-of-clickjacking-with-facebook/"&gt;The Dangers of Clickjacking with Facebook&lt;/a&gt;&lt;/strong&gt;&lt;/p&gt;
theharmonyguy compiled a list of actions that can be triggered on Facebook by a single click, and hence are vulnerable to clickjacking attacks. The list includes authorising malicious applications, posting links to profiles, sending friend requests and sending messages to other users. Why don’t Facebook include frame busting JavaScript on every page?


    &lt;p&gt;Tags: &lt;a href="https://simonwillison.net/tags/clickjacking"&gt;clickjacking&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/facebook"&gt;facebook&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/framebusting"&gt;framebusting&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/phishing"&gt;phishing&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/security"&gt;security&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/theharmonyguy"&gt;theharmonyguy&lt;/a&gt;&lt;/p&gt;



</summary><category term="clickjacking"/><category term="facebook"/><category term="framebusting"/><category term="phishing"/><category term="security"/><category term="theharmonyguy"/></entry><entry><title>Teaching users to be secure is a shared responsibility</title><link href="https://simonwillison.net/2009/Jul/16/responsibility/#atom-tag" rel="alternate"/><published>2009-07-16T20:04:45+00:00</published><updated>2009-07-16T20:04:45+00:00</updated><id>https://simonwillison.net/2009/Jul/16/responsibility/#atom-tag</id><summary type="html">
    &lt;p&gt;Ryan Janssen: &lt;a href="http://drstarcat.com/archives/133"&gt;Why an OAuth iframe is a Great Idea&lt;/a&gt;.&lt;/p&gt;

&lt;blockquote cite="http://drstarcat.com/archives/133"&gt;&lt;p&gt;The reason the OAuth community prefers that we open up a new window is that if you look at the URL in the window (the place you type in a site’s name), you would see that it says www.netflix.com* and know that you are giving your credentials to Netflix.&lt;/p&gt;

&lt;p&gt;Or would you?  I would!  Other technologists would!  But would you?  Would you even notice?  If you noticed would you care?  The answer for the VAST majority of the world is of course, no.  In fact to an average person, getting taken to an ENTIRELY other site with some weird little dialog floating in a big page is EXTREMELY suspicious.  The real site you are trusting to do the right thing is SetJam (not weird pop-up window site).&lt;/p&gt;
&lt;/blockquote&gt;

&lt;p&gt;I posted a reply comment on that post, but I'll replicate it in full here:&lt;/p&gt;

&lt;blockquote cite="http://drstarcat.com/archives/133#IDComment27455126"&gt;
&lt;p&gt;Please, please don't do this.&lt;/p&gt;

&lt;p&gt;As web developers we have a shared responsibility to help our users stay safe on the internet. This is becoming ever more important as people move more of their lives online.&lt;/p&gt;

&lt;p&gt;It's an almost sisyphean task. If you want to avoid online fraud, you need to understand an enormous stack of technologies: browsers, web pages, links, URLs, DNS, SSL, certificates... I know user education is never the right answer, but in the case of the Web I honestly can't see any other route.&lt;/p&gt;

&lt;p&gt;The last thing we need is developers making the problem worse by encouraging unsafe behaviour. That was the whole POINT of OAuth - the password anti-pattern was showing up everywhere, and was causing very real problems. OAuth provides an alternative, but we still have a long way to go convincing users not to hand their password over to any site that asks for it. Still, it's a small victory in a much bigger war.&lt;/p&gt;

&lt;p&gt;If developers start showing OAuth in an iframe, that victory was for nothing - we may as well not have bothered. OAuth isn't just a protocol, it's an ambitious attempt to help users understand the importance of protecting their credentials, and the fact that different sites should be granted different permissions with regards to accessing their stuff. This is a difficult but critical lesson for users to learn. The only real hope is if OAuth, implemented correctly, spreads far enough around the Web that people start to understand it and get a feel for how it is meant to work.&lt;/p&gt;

&lt;p&gt;By implementing OAuth in an iframe you are completely undermining this effort - and in doing so you're contributing to a tragedy of the commons where selfish behaviour on the behalf of a few causes problems for everyone else. Even worse, if the usability DOES prove to be better (which wouldn't be surprising) you'll be actively encouraging people to implement OAuth in an insecure way - your competitors will hardly want to keep doing things the secure way if you are getting higher conversion rates than they are.&lt;/p&gt;

&lt;p&gt;So once again, please don't do this.&lt;/p&gt;
&lt;/blockquote&gt;

&lt;p&gt;I hope my argument is convincing. In case it isn't, I'd strongly suggest that any sites offering OAuth protected APIs add frame-busting JavaScript to their OAuth verification pages. Thankfully, in this case there's a technical option for protecting the commons.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;Update:&lt;/strong&gt; It turns out Netflix already use a frame-busting script on their OAuth authentication page.&lt;/p&gt;
    
        &lt;p&gt;Tags: &lt;a href="https://simonwillison.net/tags/education"&gt;education&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/framebusting"&gt;framebusting&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/iframes"&gt;iframes&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/oauth"&gt;oauth&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/phishing"&gt;phishing&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/responsibility"&gt;responsibility&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/security"&gt;security&lt;/a&gt;&lt;/p&gt;
    

</summary><category term="education"/><category term="framebusting"/><category term="iframes"/><category term="oauth"/><category term="phishing"/><category term="responsibility"/><category term="security"/></entry><entry><title>Twitter Don't Click Exploit</title><link href="https://simonwillison.net/2009/Feb/12/chris/#atom-tag" rel="alternate"/><published>2009-02-12T19:56:42+00:00</published><updated>2009-02-12T19:56:42+00:00</updated><id>https://simonwillison.net/2009/Feb/12/chris/#atom-tag</id><summary type="html">
    
&lt;p&gt;&lt;strong&gt;&lt;a href="http://shiflett.org/blog/2009/feb/twitter-dont-click-exploit"&gt;Twitter Don&amp;#x27;t Click Exploit&lt;/a&gt;&lt;/strong&gt;&lt;/p&gt;
Someone ran a successful ClickJacking exploit against Twitter users, using a transparent iframe holding the Twitter homepage with a status message fed in by a query string parameter. Thiss will definitely help raise awareness of ClickJacking! Twitter has now added framebusting JavaScript to prevent the exploit.


    &lt;p&gt;Tags: &lt;a href="https://simonwillison.net/tags/chris-shiflett"&gt;chris-shiflett&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/clickjacking"&gt;clickjacking&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/framebusting"&gt;framebusting&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/javascript"&gt;javascript&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/security"&gt;security&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/twitter"&gt;twitter&lt;/a&gt;&lt;/p&gt;



</summary><category term="chris-shiflett"/><category term="clickjacking"/><category term="framebusting"/><category term="javascript"/><category term="security"/><category term="twitter"/></entry><entry><title>FB App Canvas Pages: I Think I'd Use IFrames</title><link href="https://simonwillison.net/2008/Oct/2/not/#atom-tag" rel="alternate"/><published>2008-10-02T14:39:44+00:00</published><updated>2008-10-02T14:39:44+00:00</updated><id>https://simonwillison.net/2008/Oct/2/not/#atom-tag</id><summary type="html">
    
&lt;p&gt;&lt;strong&gt;&lt;a href="http://www.ccheever.com/blog/?p=10"&gt;FB App Canvas Pages: I Think I&amp;#x27;d Use IFrames&lt;/a&gt;&lt;/strong&gt;&lt;/p&gt;
Facebook’s Charlie Cheever explains the difference between FBML canvas pages, iframe pages and XFBML when building Facebook apps. I’m always surprised at APIs that load untrusted content in an iframe, as it seems like an invitation for frame-busting phishing attacks.


    &lt;p&gt;Tags: &lt;a href="https://simonwillison.net/tags/charlie-cheever"&gt;charlie-cheever&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/facebook"&gt;facebook&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/facebookapi"&gt;facebookapi&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/fbml"&gt;fbml&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/framebusting"&gt;framebusting&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/iframes"&gt;iframes&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/phishing"&gt;phishing&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/security"&gt;security&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/xfbml"&gt;xfbml&lt;/a&gt;&lt;/p&gt;



</summary><category term="charlie-cheever"/><category term="facebook"/><category term="facebookapi"/><category term="fbml"/><category term="framebusting"/><category term="iframes"/><category term="phishing"/><category term="security"/><category term="xfbml"/></entry><entry><title>Frame-Busting Gadgets</title><link href="https://simonwillison.net/2008/Sep/17/framebusting/#atom-tag" rel="alternate"/><published>2008-09-17T23:23:38+00:00</published><updated>2008-09-17T23:23:38+00:00</updated><id>https://simonwillison.net/2008/Sep/17/framebusting/#atom-tag</id><summary type="html">
    
&lt;p&gt;&lt;strong&gt;&lt;a href="http://softwareas.com/frame-busting-gadgets"&gt;Frame-Busting Gadgets&lt;/a&gt;&lt;/strong&gt;&lt;/p&gt;
I’ve always been slightly suspicious of the Google Gadgets / OpenSocial idea of sandboxing untrusted third party content in an iframe. Sure enough, it turns out iframe busting scripts work in Gadgets, meaning a seemingly harmless gadget could potentially launch a phishing attack.


    &lt;p&gt;Tags: &lt;a href="https://simonwillison.net/tags/framebusting"&gt;framebusting&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/gadgets"&gt;gadgets&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/javascript"&gt;javascript&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/opensocial"&gt;opensocial&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/phishing"&gt;phishing&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/security"&gt;security&lt;/a&gt;&lt;/p&gt;



</summary><category term="framebusting"/><category term="gadgets"/><category term="javascript"/><category term="opensocial"/><category term="phishing"/><category term="security"/></entry></feed>