Thursday, May 1, 2008

RSS conduit to launch CSRF against MASHUPS

[Substitute "Google" with your favorite mash-up site throughout this article]

RSS feeds are slowly gaining more acceptance among the average Internet user population. Overall, my impression is that the user base is still somewhat small compared to the total Internet user base. Google, and other sites, are offering more convenient methods to access all of your RSS feeds and any other info you need. For Google, consider the Google Reader App and the Google Custom Home Page (portal). Google keeps it simple for the user, sign-in, set everything up and you're good to go. Everytime you go to your Google Home Page you see your RSS feeds and whatever other widgets you added.

There are a few problems that I've noticed here. Who are we trusting to ensure the RSS feeds don't contain malicious data, such as javascript?

Lets look at who could be the good guy and take responsibility:

  • RSS Source: We trust the RSS feed source to restrict input and only deliver safe RSS data.
    -Doubtful. Anyone can serve and RSS feed. Perhaps the bigger feeds want to avoid association with an attack and take some actions. But I doubt the smaller feeds have robust security here.

  • RSS reader widget: The actual RSS reader widget was well developed and concerned about its users, so all output is encoded.
    -Not very likely since anyone can build widgets and we know how often security holes are found in quick and dirty code.

  • Google: Google (or MASHUP X) wants to protect the user's account (since the user is logged in) and output encodes everything on the home page.
    -This is possible. Google has a vested interest to take action here. They want to protect the account of their user base. I can see them taking action to protect their users' cookies and credentials.


I've done some preliminary research on the Google home page and found that Google is taking some action to protect their users. What action is that? They are putting the widgets into individual iframes. Aside from that, not too much. Custom widges can fire scripts within their iframe (tested and confirmed) and poorly designed RSS feeds would likely be vulnerable to execute malicious RSS feed data (haven't tested yet).

Google uses iframes to separate these malicious widgets from accessing the cookie associated with Google. 1 point for google.

However, the attacker knows that a user has to be logged in with the google account to view the homepage. This account is shared with Gmail, Calendar, Reader, and so on. What if the is a CSRF vulnerability in any of these applications? An attacker will place the CSRF attack within the widget or RSS feed and the users will be hit.

More specifically, the CSRF request will be to a google domain page. While the iframe itself does not have access to the google cookies, the browser does. The browser will see the request to page x.google.com and will happily send along the user's cookie (since they are already logged in to view the google home page). End result, CSRF attack executes to perform whatever bad stuff was possible because of the vulnerability.

In Google's defense they have taken steps to prevent CSRF and I'm not aware of any outstanding issues on the moment. However, this is just an example. This issue can happen in any mashup environment.


-Michael Coates