JavaScript Scope and IntenseDebate’s Privacy Problems
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.
Your Information will be kept private.
Your Information will be kept private.
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.