Web users don’t need an introduction to Facebook’s “Like” button or Twitter’s “Tweet” button. Along with several such buttons, they help in making online presence more social and hence are called “Social Plugins”. Inserting them into a website is as easy as inserting small chunk of HTML and JavaScript. e.g., The “Like” button can be inserted by following these simple steps in Facebook Developers site. For sure, these buttons changed the way people interact on the web by building rich social graphs based on user’s tastes/interests and made the web more engaging. However, they come with certain problems in which web attackers are interested.
In a way, a social plugin converts a normal web page into a mashup, exporting a site’s data to different domains. As Douglas Crockford says, “A mashup is a self-inflicted XSS attack”. It is more of a work around than a standard and hence have few problems.
(1) Social plugins must be wrapped in iframes:
If the source of these social plugins is inspected using browser’s developer tools, one can find that these buttons are actually wrapped in iframes, for obvious reasons. A script injection attack could otherwise modify the course of action of the like button and do malicious activity. Since an iframe provides a sandboxed environment, external scripts cannot access the DOM within the iframe and hence script injection attacks fail. So if you are a web developer and want to create the next widget/social plugin for your site, iframe should be the "must have” tag.
(2) Framing a site could be dangerous – Clickjacking FTW:
In one of my previous demos, we have seen how Facebook’s “Like” button can be clickjacked (typically called LikeJacking). Iframes, which contain the code for social plugins, themselves are nodes in the parent page’s DOM and scripts can act on them, if not inside them. So in the demo, I have grabbed the x,y coordinates of the iframe containing the “Like” button and changed them dynamically as the mouse moves. Thus one can place any social plugin beneath the user’s mouse cursor and reduce its opacity to zero. The implication is, clicking anywhere on the page means clicking on the social plugin!
Clickjacking can be countered by using JavaScript based “Frame busting” techniques or configuring X-Frame-Options response header. Using these techniques, a web page which is framed will be forced to come out of the iframe, thereby preventing clickjacking.
The problem: Now, have you sensed the problem? If not, pause and analyze the ideas in (1) and (2). In any case, proceed :)
Here is the problem - As per (1), a social plugin has to be in an iframe to prevent script injections. As per (2), content (typically from an external website) has to be pulled out of iframe to prevent clickjacking. Now both are contradictory ideas.
Inference:- “A social plugin cannot exist securely without being wrapped inside an iframe and hence it is always vulnerable to clickjacking!” Alarming!! Isn't it?
(Q) So what if social plugins are vulnerable to clickjacking?
(A) You will continue to see different types of spams on social networking sites due to ignorant clicks of users on hidden social plugins. Social networking sites have to depend on algorithms to detect anomalous behaviors, since there is no solution available right now to stop this.
Further, this can lead to new types of web based attacks. One such possibility is explored by researchers at Carnegie Melon University. They demonstrated how social network users can be de-anonymized using clickjacking, which is an interesting case study.
Hope the article helped in understanding the technical flaw with which most websites are living. I have been experimenting on these lines and came up with yet another interesting case study. More about it in my subsequent blog posts. Happy learning!