I am not entirely sure whether people pass off security articles, they’ve always intrigued me. I suggest you don’t skip this one whether you’re involved in OpenSocial or not.
Before I get into the meat of the article, a few things need to be understood, notably what is XSS and CSRF? I’ll explain this in layman’s terms as opposed to sounding like a wikipedia article. Please research on your own if what I say makes no sense as it’s a pre-requisite on understanding this article and every programmer in the world should know what this is.
XSS (Cross-site scripting): XSS is a way to execute javascript on webpages around the web that would otherwise be unintended behavior. Essentially, imagine you have a comment form, someone can create a comment with text input that allows them to execute javascript on your browser. In this imagine me sending Ajax POST requests to your bank account to withdraw $1000 and put it in my account. The transaction was on your behalf because javascript is executing in your browser and is therefore a valid, non-disputable transaction as the request will have originated from your IP address.
CSRF (Cross-site request forgery): CSRF is very simply session riding. We all have seen sites that contain a url as such: http://www.url.com/?action=logout. In this case, imagine if I redirected you to that URL, gmail would log you out. Not too glamorous huh? Well imagine for a minute, I created a form on MySpace, then created a 1×1 iframe and opened a URL to post a bulletin out to all your friends on your behalf. You would’ve never known it happened and you would move along. This is the power of CSRF.
Combine XSS with CSRF and you have a catastrophe in many cases exhibited by the Samy Worm on MySpace. If you don’t know what I am talking about, Google it =).
If these became eye openers to you, continue reading. If you’re just brushing it off research a little more and the continue reading and perhaps I’ll be able to convince you.
The meat:
So what’s OpenSocial have to do with all of this? It’s secured in a nice little iframe off the container’s host right? Sure, that’s a step in the right direction however there’s much more of a problem:
Let’s walk-through how OpenSocial has been architected from a developer/hacker perspective:
- A javascript function called makeRequest() as a way to proxy Ajax calls to servers to GET/POST data.
- OpenSocial applications utilize both REST and pure non-filtered Javascript as a means to design applications. A majority today use Javascript as it is cross-compatible.
- OpenSocial contains virality mechanisms such as requestSendMessage() and requestShareApp() and activity streams as a means of spreading amongst users.
- Finally, OpenSocial is able to grab user data such as a uniquely defined user id, gender, location, etc. The same is true of an application viewer’s friends.
In some social networks, they use the actual user id on the social network as the opensocial id. These networks include MySpace.com and hi5.com. This means that I can grab a list of all my friends’ opensocial id’s which also happen to be their real id’s on the network itself. Remember this.
OpenSocial is a viral channel to the distribution of any web exploit on the internet today. “Web 2.0″ is often associated with socializing, networking, etc. OpenSocial is a new age mechanism of the exploiting, called it “Exploit 2.0″ though that’s a silly buzzword–don’t spread it around!
I am going to say something very bold: The internet is only one XSS exploit away on any social network hosting an OpenSocial application from getting infected.
Let’s try a proof of concept:
MySpace a few weeks ago contained an exploit that allowed people to use XSS and CSRF as a means to private message any user on the behalf of the person viewing the application. All these people needed was a user_id. MySpace protects it’s forms from CSRF by using a session hash in their forms that must match something on their backend–best way to defeat CSRF. Anyhow these people managed to get passed it via some sort of XSS hole, nonetheless they created an invisible iframe, created the form, set the target to the iframe, and submitted the form on your behalf. Beautiful and tricky, it’s pretty cool–nothing new though.
The problem with create XSS worms on the internet today is that they require a static element to them. For example, I once found an XSS hole in Facebook’s politics application, unfortunately the hole showed up on Facebook profiles. So I was able to literally execute javascript on my profile. I quickly changed my user input after a quick test and I linked in an external script to be executed on Facebook.com’s profile pages. That means I have complete control over Facebook to do whatever I want. So, of course, I am not completely malicious I simply photoshopped an image of Facebook, made it suhailBook and any time you visited my Facebook profile you would see the new suhailBook logo. It was priceless, however I started thinking more into it and realized that because I have complete control over Facebook, I could also send a request to the politics application to inject the same javascript file on any viewer to my profile on their behalf. The static element was that my user input was stored and could actively execute on the profile. I didn’t need to spam a url around and slowly infect people, I could exponentially do it. Every time someone viewed my profile, they would be infected and then become a host to spread it until the entire Facebook became suhailBook. This was all just a proof of concept, the hole was documented and fixed the same day.
The point is, OpenSocial IS that static element, the applications are contained on the profile pages of users and are allowed to execute javascript and API specific calls. Now imagine, I’ve found this way to privately message all of your friends to install the application on your behalf. As soon as they do they send out a spam message to all their friends. You now have exponential growth based on the ratio of conversions you get from that message.
Let’s take it a bit further, imagine you found a way to automatically install the application just by VIEWING a profile. You have OpenSocial as your static element to virally spread (because it sits on the profile) and an exploit to auto-install. Exponential growth.
If you take it one bit further, imagine you spread a 0-day exploit because of holes in Adobe Flash, Adobe PDF, or Quicktime? Exponential infection on an OS level.
Any social network that has even 1 XSS hole let’s an OpenSocial application spread itself exponentially. The application uses it’s weight of knowledge based on user data (like user id’s) and static placement on profiles can infect users simply by opening an iframe to myspace, orkut, hi5 and injecting the external js file to commit requests on behalf of a user. This is dangerous and this channels huge viral effects if you can spread the application virally at the same rate as infection. You can channel XSS and CSRF to do almost anything, change an image, edit a status, post a comment, post a blog entry, etc ,etc.
In some cases, you don’t even need an XSS hole, all you need is a little bit of CSRF. This is a funny case but imagine everytime someone installs your application or even views it, you decide to attempt to remove your competitors application via CSRF.
Another concept is that, XSS and CSRF are interesting ways to exploit but they aren’t very fun if you don’t have a popular website people go to so you can fool. OpenSocial doesn’t just provide avenues to exploit the containers but it presents avenues to exploit OTHER websites as well, like PayPal, Facebook, etc. You have this profile that’s highly trafficked and low and behold a malicious OpenSocial application that can open up iframe’s ANYWHERE it wants to and commit attacks on any site in the world. As the application spreads so does the rate of infection to other sites. These attacks are hard under normal circumstances because malicious sites are generally unpopular–you can’t profit very much off 10 people visiting your blog that has a hidden iframe stealing email lists from anyone that is logged into a yahoo account via XSS (this was once possible FYI). On MySpace, I can open up an iframe, inject my javascript, steal the whole email list of yahoo contacts from any user that is currently logged in, and send the data to my server which is continually harvesting them. Nobody would really notice because it’s not hurting anyone directly. I can harvest millions given the popularity the user whose profile is being seen. Who is protecting against that?
You may say, sure you have to find one XSS hole first. That is trivial and extremely easy give the attitude that XSS and CSRF are small exploits. In this environment, the tiniest exploit can have devastating effects. I promise you, just because these are big companies doesn’t mean their programmers forget to sanitize and secure inputs and forms respectively. I’ve found XSS on Google, Ning, Facebook, hi5, MySpace, Digg, etc. Ever heard of them?
You have 3 huge social networks using OpenSocial today, more will follow as people note their success.
There will be someone out there that has the courage to do this and you won’t even realize you were hit. OpenSocial needs to draft a change in security today, not tomorrow.
No one is protecting their users, every network has completely circumvented nearly every security measure they have placed and have destroyed many aspects of their site they took a lot of time to harden because of the 1 XSS hole to exploit concept.
Caja is not the answer. If you’re ready to piss off 1-5k+ developers and tell them to rearchitect their code, good luck. Oh and how is Caja going to stop me from Ajaxily requesting a script on my server? It’s not the answer. Manual code reviews do not scale. FBJS was a great solution and probably the only smart one.
There is no mechanism on the internet today which invokes this new paradigm of infection so easily and is what makes OpenSocial a global unparalleled security risk.
