JavaScript Scope and IntenseDebate's Privacy Problems

Tue, 26 Apr 2011 - by Ferruh Mavituna

In this web application security article, Ferruh Mavituna, explains a security issue he identified in IntenseDebate online service that could allow attackers to access information about the logged-in session of the victim. Ferruh also suggests a number of remedies for this problem which every web application developer should know of.

I like IntenseDebate a lot, they allow web developers to embed a comment system to their websites. It's easy to implement but more importantly it allows visitors to comment with one shared account among many websites to avoid logging into every single website just to write a short comment.

Their implementation is straight forward:

  • Website owner embeds IntenseDebate's JavaScript into the blog page
  • User logs in via IntenseDebate's website
  • Now user can comment in different websites without need to log in again

What's the problem

  • IntenseDebate's JavaScript dynamically generated and includes currently logged in users' information
  • This JavaScript embedded in the registered website which means the embedded website (i.e. attacker.com) can access the content of the embedded JavaScript


Now if you step back and connect the dots that you'll notice any website can access the IntenseDebate username of the visitor. This means that when an IntenseDebate  user visits the website, the website can identify the visitor even if the visitor didn't leave a comment.
It's kind of creepy for IntenseDebate users because you might have been identified by different websites while browsing the web.
In JavaScript to get this data all you need to do is wait until IntenseDebate JavaScripts load and then read the following string:

var data = eval('(' + str + ')');
var cuser = data['username'];

Now cuser holds the currently logged in user's username. The next line can save it to a database:

$.post("/AjaxSave.aspx",{user: cuser})

See it in Action

Demo (you need to logged into IntenseDebate)

How to fix

It's a known fact that storing session sensitive information in JavaScripts is bad (think JSON/JavaScript Hijacking) so you shouldn't do it. In IntenseDebate's case though this is by design.
A better way to design this using iframes is to force loading sensitive data in different domain. That's what Facebook and several other similar companies do.

Responsible Disclosure

We got in touch with IntenseDebate on the 26th of Jan and then to follow on the 31st of March, I tried hard to explain them the problem, gave them a live proof of concept and explained the problem in details yet didn't get any results. I hope this blog post will attract some attention from them and they'll address this problem as soon as possible.

 

Your Information will be kept private.

Ferruh Mavituna

About the Author

Ferruh Mavituna

Ferruh Mavituna is the founder and CEO of Invicti Security, a world leader in web application vulnerability scanning. His professional obsessions lie in web application security research, automated vulnerability detection, and exploitation features. He has authored several web security research papers and tools and delivers animated appearances at cybersecurity conferences and on podcasts. Exuberant at the possibilities open to organizations by the deployment of automation, Ferruh is keen to demonstrate what can be achieved in combination with Invicti’s award-winning products, Netsparker and Acunetix.