Stumbleupon Cross-Site Scripting Vulnerability

While I have previously identified XSS and/or CSRF vulnerabilities in both Digg and Reddit, Stumbleupon has largely remained innocuous to these types of attacks for multiple reasons. First, the primary method of user-login and authentication is through the toolbar, which makes it substantially harder for malicious javascript intercept. Furthermore, because many of the many valuable user functions are triggered through the individual’s personal subdomain (user.stumbleupon.com) and www.stumbleupon.com, it becomes quite difficult to execute complex functions such as auto-voting or friend-adding.

That being said, there are still work arounds that exist. In the proof of concept I was able to execute, the vector of attack was the invitefriends.php file which does not sanitize the email1 input.

http://www.stumbleupon.com/invite_friends.php
?sendername=n&message=n&[email protected]&email1=[[vulnerable field]]

Subsequently, if an individual is logged into the Stumbleupon website (not simply the toolbar), you can hijack their account to perform multiple tasks, but are still limited to their homepage. One of the first tasks we need to do is acquire the users temporary fauth/ftoken id, which Stumbleupon uses for form field authorization. If Stumbleupon.com simply generated a new fauth/ftoken every time a form is called, they would have stopped this vulnerability immediately. However, because the fauth/ftoken is the same across the site, it becomes quite easy to simply grab the fauth/ftoken from the URL submission page (http://www.stumbleupon.com/url/[[a url]] via an AJAX request and simple DOM calls.

This can be then used in conjuction with the REST method for adding friends… http://www.stumbleupon.com/user.php?friend=[[insert your numeric ID]]&fauth=[[the fauth]]

Of course, the effectiveness of this attack is greatly diminished by the fact that the user has to still have session cookies from an actual website login to StumbleUpon – not just via the toolbar.