Presentation on HTML5 Security, Part-2 - OWASP Hyd

In continuation my previous talk on HTML5 Security at OWASP Hyd, I have covered few more interesting concepts at OWASP Hyd August meet. Slides are more or less the same as my previous session but it was more demo driven where I've shown known security problems and secure coding practices to be followed while using HTML5. 

I've been committing some of the basic demos whenever I find time into my github account. I shall blog more about some interesting topics very soon.

A note on JSONP & misconceptions of Cross Origin AJAX

Web developers who have worked on accessing APIs using JavaScript would be very much familiar with the term “JSONP”. Many web devs whom I have met offline or in online discussion forums seem to have some misconceptions about JSONP. Below are some of the basic & common definitions which I have come across:

  • JSONP is a technique to work with remote APIs
  • It is nothing but Cross Origin AJAX
  • If we add a query string like “?callback=someCallback” and fire jQuery’s $.ajax or $.getJSON, what we are doing is nothing but a JSONP call.
  • May be a slightly complicated definition: Cross origin AJAX is possible only when the response thrown is JavaScript
  • and many more..

The truth in the above statements is very little and such definitions add more confusion, bringing in misconceptions. In my recent presentation “Content Isolation with Same Origin Policy”, I put up the below slides (check slides 4 & 5 in the ppt)













For all practical purposes, the first one is possible and second one is not. Apart from the tweaked definitions of JSONP as stated above, the below reasoning complicates the topic:

  • In the first case, the content requested is of the type “text/javascript” while in the second case it is HTML. So browsers look at content type of the response header and decide whether they should block the content or not (actually, a very good observation).
  • There is a “?callback=?” parameter in the first case enables jQuery to make the cross origin call in the first case
  • Server side framework should have special capabilities (Iike inbuilt serialization/deserialization) for the first case to work

I thought it would be nice to summarize few facts and hence this post. Read on.

What's an Origin?

The combination of scheme://host:port is what browsers treat as an Origin. e.g.,,, belong to different origins as they differ in one of scheme, host or port. Remember that and are different URLs but not different origins. Also, a domain ( and its subdomain ( belong to different origins (this particular restriction can be relaxed using a technique called domain relaxation, which is out of scope of this topic).

Can my client script read your emails?

Browsers restrict JavaScript calls to server (read as AJAX) based on Origin. This is governed by a policy called Same Origin Policy. In other words, client script in your page can make calls only to your server (strictly speaking, origin). If this rule wasn’t there, it would have been possible to write a script in some arbitrary web page which can read your web based email conversations.

Cross Origin AJAX? Really?

For the reason stated above, a page can make an AJAX call to the same origin from which it originated. If I am allowed to coin an acronym stressing on the boundaries of AJAX, I would coin “AJAX-FOO”, which expands to “Asynchronous JavaScript And XML For Own Origin”. As soon as a new XMLHttpRequest is fired to a remote origin, browsers check the origin of the page with the destination of the request. If both are same, the call is allowed. Else, the call is blocked with an appropriate error message. So there is nothing like Cross Origin AJAX.

Understanding JSONP (TL;DR: It’s all about script tag hack!)

As they say, necessity is the mother of invention. When web2.0 APIs were introduced, they desperately wanted cross origin interactions. JSNOP was discovered as a hack/work-around to bypass the restrictions of Same Origin Policy.

The idea behind it is very simple. Same Origin Policy doesn't apply for scripts (and a couple of other elements too). A <script> tag in a web page can load JavaScript from any origin (i.e., when you embed jQuery.js pointing to a CDN, loading from a remote origin is allowed). Using this loophole, one can create cross origin requests.

Simple example to create your own JSONP service

1. Create a HTML page having two JavaScript files. In script1.js, create a function “processData”

function processData(data){ 
console.log('Hello '+data.firstName+' '+data.lastName);

2. In script2.js execute the above function by passing valid JSON data:

processData({firstName:'Krishna', lastName:'Chaitanya'}); 

3. When you load the page, both the script files load, code in the second file executes the function defined in the first file. This is an expected behavior.

4. Create a file “” (yes, create it with this dummy extension. This is going to be your web service) and place it in the same folder. Open it and write the same code as in step 2. Now open your web server (IIS or your preferable one), go to your site, open mime types section and add a new mime type “.abc” having the mime type value “text/javascript”.

5. Now remove reference to “script2.js” and add a reference to this new file “” in the head section like this:

<script type="text/javascript" src=""></script>

6. When you load the page now, you get the same behavior as that of script2. So far, everything is in the same origin. Place the file “” in another origin (simply create another website on a different port number-recollect that different ports means different origins) and reference it in script tag and the code still works.

What you have done is, you have loaded content from a remote service via script tag injection. This is the essence of JSONP. The idea of having a random file format “.abc” is just to show that any file which can serve script content will hold good for this. You may use your “.aspx”, “.asmx”, “.ashx” or whatever to achieve this.

Hence, JSONP is always a script Injection and has nothing to do with XMLHttpRequest object and AJAX.

How JavaScript libraries like jQuery help (mislead) you

If you use libraries like jQuery, they give you a common syntax which works for AJAX as well as JSONP hack. They do a lot of work behind the screens to make a JSONP script injection

$.getJSON('', function (data) { 

In the above API for Facebook, if the value for callback is given by the developer as “”, facebook returns json data by wrapping it in the function “fetch” (open the link in your browser and check the output. Note: IE will ask to save the response as ".js" file.). If the function name is omitted, jQuery handles it in an interesting/tricky manner. It takes the success callback as the function to be executed (similar to “processData” function as declared above), creates a random function name and assigns the callback to it. The server too responds by wrapping its json data in the random function name which it got from the request (see the first screenshot in this blog post). Once the http transaction is done, jQuery destroys the random function.

(Note: To test the trick jQuery uses, I used burp proxy to intercept and pause the request sent by jQuery. While pausing, I typed jQuery’s random function name in browser’s console and it printed the definition of the function. After the response is received, I did the same and I got that function is undefined. This way I was able to deduce the trick jQuery uses for JSONP).

In this process, jQuery does not fire an AJAX call. All it does is injection of script tag and serving javascript in its response. Since the syntax for AJAX and JSONP are maintained the same, web developers tend to confuse about JSONP.

So what mime-type should be served for a successful JSONP request?

Well, this is a topic of confusion, at least for me. Since the served content is JavaScript, the preferred mime-type should be “application/javascript” or “text/javascript” or may be "application/json". In my demo, I’ve changed the mime type of the above service to “image/gif”, “text/css” etc and the script still worked in all modern browsers without any warnings. Also, there are cases where browsers show a "save file" dialog when wrong mime type is served. Enabling adhoc mime types has security concerns and research is being done in this area for standardizing mime-type. At least for now, “application/javascript” can be used and anyways CORS is the future, so no more content type worries.

Hope the article provided useful info. Share your thoughts or discuss if you see the need for any corrections. Happy coding Smile

Browser Internals: Content Isolation with Same Origin Policy-Microsoft UG Dev Day

Microsoft User Group Hyderabad (MUGH) has organized Developer Day at Broadridge Financial Solutions, Hyderabad this weekend. It was a half day event with very good line up of sessions and I had the opportunity to present on a very exciting topic-"Content Isolation with Same Origin Policy".

"Same Origin Policy (SOP)" is one of the foundations of web security, which is built into web browsers. Web developers often do not understand this policy clearly and work with several misconceptions. The goal of this session is to show how important SOP is for the web, how it is bypassed using hacks and what HTML5 offers as a standard to overcome its limitations. Getting a full understanding of SOP isn't easy in a one hour session as it is relatively vast and complex. However, I have tried to simplify several ideas and put them in one place in the slides. Folks who couldn't attend the session will also be benefitted from the slides.

Along with my talk, there was an interesting talk "One Service, Any Device, Any Platform-Web API" by fellow MVP Shravan and "A Lap around the new Windows Azure" by our super techie Phani, cofounder of BrainScale. It is really motivating to see close to 100 techies coming to learn cutting edge stuff over a weekend. That was a great time spent! See you in the next tech event. Happy coding :)

HTML5 Sandbox and some notes

While building mashups, one of the primary goals is to securely isolate content coming from different origins. Generally, client side mashups are built in one of the two ways-(1) Embedding third party scripts in a web page (2) Loading remote content via iframes. Embedding scripts provides more interactivity but dilutes security since the scripts run with full privileges and could be malicious. Using iframes reduces interactivity but enhances security since they isolate content via same-origin-policy (Script inside a cross-origin iframe cannot access DOM of parent page).

[Note: By chance if you are wondering why you should bother about mashups since you have never built them, you are mistaken. If you are embedding scripts for website analytics, social plugins (Like, Tweet, +1 etc.), advertisements, comments system (e.g., Disqus) and so on, you are already having a mashup!]

Though iframes follow same-origin-policy and provide security in some sense, they are well known for their notorious activities like frame phishing, top window redirection, clickjacking, triggering drive by downloads etc. The “sandbox” attribute for iframes which is introduced in HTML5 promises to thwart the problems caused by iframes. Sandbox is currently supported only in Internet Explorer 10, Chrome 17+.

A sandboxed iframe by default disables script, popups, form submissions, top navigation etc. Some of the restrictions can be relaxed by specifying space separated white list tokens (allow-forms, allow-scripts, allow-same-origin, allow-top-navigation).

<iframe sandbox src=""></iframe>
<iframe sandbox="allow-forms allow-scripts allow-same-origin allow-top-navigation"

The details about sandbox and its white list tokens are discussed in several blogs, hence purposefully omitting it here. One interesting feature in sandbox is, when a sandboxed iframe loads content from the same origin as the parent document, the loaded content is still treated as if it originated from cross origin, thereby reducing its script privileges. This restriction can be removed by using the token “allow-same-origin”.

Below are some of the cases where developers have to be cautious while using sandbox.

Disabling Clickjacking Defense:

Even till date, several sites rely on JavaScript based frame busting defense to get rid of clickjacking (X-Frame-Options response header is a better defense, but unfortunately has lesser implementation). Such sites when embedded in a sandboxed iframe are greatly affected. Since sandbox disables JavaScript, the clickjacking protection used in the framed site is lost, hence back to square one!

Allow-scripts and Allow-same-origin combination:

This combination of tokens is a little tricky and could negate the effect  of sandbox. The “allow-scripts” token enables JavaScript inside iframe and the “allow-same-origin” token will give the iframe complete privileges to access DOM of the parent. So if the embedded iframe has a vulnerable input field, script can be injected to remove the “sandbox” attribute altogether and then carry further exploits. Thus the security benefits of sandbox can be removed completely.

Effect on Nested Browsing Contexts:

If a webpage has nested browsing contexts (page containing an iframe which in turn loads another iframe), then reasoning about the effect of sandbox tokens becomes complicated. Let us consider the scenario in the image on the right below-a parent page has an iframe to a page (Child1) with "allow-scripts" sandbox token. Child1 loads another iframe which points to Child2 having "allow-forms" token. At a quick glance, developers may conclude that the innermost page will have both forms and scripts allowed, but it is on the contrary. The inner page has everything disabled and for a good reason! The child1 frame has forms disabled and it will overwrite the "allow-forms" of Child2. Also, Child1 has scripts enabled but Child2 has them disabled. Hence it does not allow script execution. So it is advisable not to manipulate sandbox tokens dynamically, since it is difficult to reason about the after effects on sandbox restrictions.

DEMOS: Click the images for demos (Source at: )

Sandbox demo 1

Sandbox demo 2










In the first demo, there is an iframe with JS based clickjacking protection and by default sandbox option is selected. You can see the clickjacking defense by selecting “normal frame”. So this shows how sandbox defeats JS based clickjacking defense. Also in the same demo you can select “allow-scripts” and “allow-same-origin” optons and inject the snippets provided below the page into the XSS vulnerable page.

In the second demo, inspect the iframes and load them independently in different windows and to see the effect of sandbox tokens in nested browsing contexts.

Hope the article provided some useful information about HTML5 Iframe Sandbox and its secure usage. Feel free to get back with queries or please share aspects which you feel interesting about Sandbox. Happy coding Smile

Presentation on HTML5 Security-OWASP Hyderabad

Happy to say that I had the opportunity to present at OWASP Hyderabad chapter on "HTML5 Security" on 19th May, 2012. The event had awesome audience from diverse backgrounds in security domain-security researchers, penetration testers, security consultants, few developers etc. The talk went for about 2.5 hours(yes!!) and was quite interactive. The audience were very patient, passionate and we had lots of discussions on several interesting topics.


I have built some cool demos for the presentation but the code is not well organized. I shall clean the code and upload to my github account shortly. I would be continuing this talk in next month's OWASP meet too.

Microsoft MVP Award and my two cents

First of all, I’m really happy and proud to say that I’ve received Microsoft Most Valuable Professional (MVP) award for the third consecutive year. YaY!! I’ve received my first MVP award in 2010 under “ASP.NET” category and in 2011, 2012 under “Internet Explorer” category. Kudos to Microsoft which uniquely recognizes and values its experts through the MVP award program.

So, how to become a Microsoft MVP? Well, this is the most frequently asked question in most of the user group meets, email conversations etc. Fellow MVP and friend Vijay Raj wrote an excellent blog post on this which gives great inputs.

My MVP story:

My first encounter with an MVP happened through a series of email discussions 4 years back (January 31, 2008 2:52 PM to be precise! I was just 6 months old in software field). At that time, AJAX start pages were highly popular and, a Web 2.0 mashup built in ASP.NET created a revolution. I wrote a long mail to the owner of with lots of enthusiasm and many queries like how he built the awesome product, how I can be a techie like him etc. I didn’t expect a reply, but was overwhelmed when I saw his reply the next day. The owner was Omar Al Zabir (Microsoft MVP for 7 years!) and he replied to my mail with this interesting link-How to become a good developer overnight! (Strongly suggest you to read this!!!).

Omar’s post had a strong influence on me and I was determined to work with passion (the MVP thing was completely out of my sight). I started with creating a web mashup something like PageFlakes in the next 4 months. Here it is!. Though it wasn’t complete and rich enough, given my experience and knowledge, that was big and the learning I had was huge!! I felt like sharing my experiences and captured them in my blog. Also, I took my learning to ASP.NET forums and helped developers who are struggling with similar problems.

Then came jQuery using which I rebuilt my mashup page (purely client side). I was learning and contributing extensively on JavaScript, AJAX, front end performance tuning, JS design patterns, jQuery plugins, browser compatibility etc. at forums, blogs, online events and MUGH for about 2 years. Suddenly, on 1st April 2010, I got a mail that I am a Microsoft MVP! Of course, I wasn’t alone throughout the journey and I was guided by amazing folks within and outside Microsoft. Thank you all for molding this wet clay!

The moral is, I worked rigorously with lots of passion and shared my learning, without worrying about “how to become an MVP”. Year on year, I maintained my consistency in learning and sustained sincerity without worrying if my award will be renewed. If Microsoft had not come across my profile, I wouldn’t have been an MVP but still I would be having my hard earned learning with me, which is the key towards a bright career. If you are a new MVP, just don’t get sick and count days before your MVP renewal date (am not kidding!). There is a lot to life beyond an award.

By the way, if you too are passionate and find all this interesting and relevant, tweet me for any help. I still remember how much I looked for help.

My gyan for fellow/new/wanna-be experts:

In the past 3-4 years, tech community has grown a lot. Thanks to Twitter/Facebook which made tech communication across geographies easier. There are several passionate developers, new MVPs every quarter, promising community folks etc. whom I/we interact with. While many of you are doing it right, here are few tips for those who are doing it wrong! (Strictly my personal opinions/beliefs and no way related to MVP award program).

  • Focus on gaining depth and hands-on expertise in the technology/area of your interest. Don’t just be news aggregators-there are enough social media sites for this purpose.

  • Please, please don’t try to impress existing MVPs, folks from Microsoft on Twitter/FB for the sake of award or other expectations. If you are an expert and contributing genuinely, Microsoft will find you and reward your efforts.

  • At any point of time, quality beats quantity. If you are writing, say, 365 blog posts/year all alone, you need to question the quality of your learning. There is enough documentation on “How to create a new ‘xyz’ application in visual studio” at MSDN. If you refer MSDN articles, explain the same with screenshots and call it expertise, I pity your ignorance.

    Instead, build something which solves existing technical challenges or dives deep into a subject and show it to the world. Doesn’t matter even if you write 1 or 2 blog posts per month but make sure your learning is rock solid and has good impact.

  • Microsoft is definitely one of the best employers to work for. However, don’t look at MVP program as an entrance to bag a job at Microsoft. Understand what you really want to do with the expertise you gained. Be patient, don’t be desperate and hasty.

  • Just that you want to be an MVP or you are a new MVP, you need not kill your instincts, become a fanboy and boast about Microsoft’s products/technologies. Stop that. Appreciate the good, help improvise the bad.

  • You are/wanna be a tech expert and not a sales representative. Speak the internals and stop surviving with “new features in xyz language”.(e.g., If you love programming, at least know closures, continuations, callbacks, recursive programming etc. Learn Lisp or may be Scheme and see how ideas in them are related to the new features in C#. You will love your code.)

  • If you are working on Microsoft technologies/products, it doesn’t mean you should not work on open source ones. How many of you have appreciated the beauty of Git and GitHub? There are some brilliant projects on GitHub which you can fork/follow and learn. Do you know that you can set up a full fledged blog on GitHub for free using Jekyll (a ruby gem) & Disqus?

  • Don’t convince yourself that you have read the entire material on a particular technology and you don’t have anything to do till the next version releases. Foolish!
    Just check the extraordinary and evergreen research going on at universities like Stanford, Berkeley, CMU. You will be amazed. When you are writing about HTML5 syntax in your blog, researchers are coming up with innovative ways of solving severe security flaws at protocol level and giving you a simple syntax. Grow up and widen your learning.

Hope the post provided useful information and motivated you enough for gearing up to the next level. Let me know what you feel in the comments below. Happy learning! Smile

What web devs should know about HTTP ”Referer” header

Every HTTP request has a set of Request Headers which carry pieces of useful information from the client to the server. One such request header is the "Referer" header, which contains address of the previous page from which the current page was requested.

E.g., If you search for "HTML5" on google and click on the first result (link to wikipedia's page), you would be navigated to Wikipedia's HTML5 page and the "Referer" header contains the address of the previous page (i.e., google's search results page). Check the details in the below screenshot of IE9 F12 toolbar.


Over the years, “Referer” header (actual spelling should be “Referrer”, but it was misspelt in specs itself :p) has been used in several useful scenarios.

Fun with referrer:

By using “document.referrer” property in JavaScript, the address stored in referer header can be read. Using this web pages of Web 1.0 era displayed welcome messages, special offers, redirected to personalized landing pages etc.

if (document.referrer != ''){
alert('Hey! Welcome from '+ document.referrer);

CSRF protection:

Cross Site Request Forgery (CSRF) is a well known web based attack using which an attacker can make requests on behalf of the user. Leveraging CSRF, an attacker can construct GET/POST requests in a web page and make the victim open the page.

<!-- If this image tag is injected, it generates the below dangerous GET request -->
<img src=""/>

To defend against CSRF, the server has to differentiate between HTTP requests originating from a genuine user’s page vs an attacker’s page. Protecting against CSRF is a well explored area and it has several defenses such as using secret validation tokens, custom headers, Referer header etc. In most cases, the Referer header is used to check if the request is from the expected domain and not from attacker’s domain.

However, security experts have shown that referer headers can be easily stripped (Kotowicz’s demo) in all browsers and hence majority of CSRF defenses depending on referer header will fail.

Privacy Concerns:

In the era of social networks and personalization, data has become the currency of the web. By looking at the referer header, advertisements can learn from which page a user has visited the current page and provide more relevant ads. This means the browsing habits of users are being exposed to the cloud (Watch this Defcon video- How our Browser history is leaking into the cloud).

Till recently, Facebook exposed user’s unique Id in Referer header which caused serious concerns. Sites which are too concerned about privacy prefer to strip referer header and stay safe.

Damn! What web developers frequently use in their requirements is in fact not a recommended practice! Solutions are coming up!

Origin Header:

Researchers at Stanford Web security lab proposed that a new header called Origin Header should be used to uniquely identify requests. It is different from Referer header in that it just contains the origin (scheme://host: port) and not the entire address of the previous page. So this removes the privacy concern and can be used as protection against CSRF.

As far as I’ve seen, Origin header is implemented in Firefox, Chrome as an experimental feature and needs standardization (needs further verification).

Noreferrer: HTML5 introduces a new link type attribute called “noreferrer”. When an anchor tag is decorated with “rel=noreferrer” attribute, the pages which follow the hyperlink will not include referrer information in the header. This would pull down the privacy problem caused by Referer header. As of now, no browser supports this ‘noreferrer’ attribute.

So, the take away is, HTTP Referer header may be a handy option but it bears its own security and privacy problems and hence should be evaluated carefully. Instead, Origin header would be an ideal solution which would cater to the needs of web developers, respecting security and privacy.

JSFoo Chennai 2012–”JavaScript is mischievous. Handle 3rd party content with care!”

It is always exciting to attend a technical conference focusing on a particular theme and even more if you get the opportunity to present. Continuing their good run, HasGeek has organized JsFoo Chennai 2012, India’s first JavaScript conference series, at IIT Madras Research park. There were several interesting proposals made and mine got voted for the final schedule along with other awesome entries.

My session is about the security considerations one should think of while integrating 3rd party JavaScript content into their site (in other words, security of web mashups). 


Presentation: Click here

Demos: Recursive Mashup Attack and Clickjacking

Learning aside, the best part is, I’ve met several awesome passionate geeks, few whom I know on twitter and few I would have never met otherwise. Loved the event even more, since people working on different platforms and having good expertise in JavaScript came under one roof and discussed. Diverse opinions and lots of learning!!

For those who missed, check JsFoo site for videos of sessions, which will be uploaded shortly. Also, here is an interesting review written by one of the attendees.

Secure Web Messaging in HTML5–Microsoft UG Dev Day

Happy to say that I have presented on this interesting topic at Developer Day organized by Microsoft User Group Hyderabad (MUGH). Not sure if any other monthly User Group meet would attract 150+ audience over a long weekend!


Presentation: Click Here

Demo: Click Here

The half day event went very well with 3 exciting sessions – Coding for fun with Kinect by Abhijit Jana, “I Love HTML5” by Shravan and the above session by me. All the sessions were very interactive and we had a very good technical weekend. Hope the huge turnout continues for rest of the events in the User Group :)

Social plugins-winners of the modern web, with weakness!

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!

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