Devrandom

OpenSocial insecurity - no user to app authentication

· Social Networks

I was pretty excited to hear about Google trying to set a standard for social network applications. I wasn’t so happy to notice a serious omission in the way security is handled. Executive Summary: no user authentication! Any user can forge anybody else’s identity when interacting with any OpenSocial application. As it currently stands, it is not possible to write secure social applications on the platform. For example, with any messaging application, anybody could message another user’s friends and it will seem like the latter did it. Or they could post embarrassing material and it would look like someone else posted it. Or they could read any information that is supposed to be shown only to the application user, such as private notes. Details: in order for an application to securely handle user data, it must know who the user is. Also, it should not be possible to impersonate a user. For this to happen, it is not enough for the client-side (e.g. JavaScript) to pass the user-id to the application back-end. It must also pass some kind of token that authenticates the user and cannot be forged by third parties. For example, it’s not enough for a container name (e.g. “orkut”) and a user id (e.g. “123456789”) to be passed. You’d need another piece of information that could only be generated by Orkut, in order to prove that this really is their user and that it’s not a random third party claiming to be the same person. If you don’t do this, anybody can look at the JavaScript code in a debugger and substitute whatever user ID and container name they want. They will then be able to deface the application by taking any action as the original user and be able to read any private information stored in the application on behalf of that user. How FaceBook does user authentication: Facebook provides a secret key to the application developer. This key is stored on the server-side of the application and is never transmitted on the wire. Facebook signs the security sensitive headers of the request, including the user ID. The application can verify the signature using the shared secret key. This is a relatively standard way of performing authentication and Facebook gets it right. How this could be implemented in OpenSocial: A solution can be constructed by use of authentication namespaces, secret key exchange and signatures. A user ID would be a URL of the form: https://orkut.com/container/people/12345 where https://orkut.com/container/ is the namespace and 12345 is the user ID. The application XML descriptor would include a callback URL. The callback would happen in two stages: first the container hits the callback URL to inform the application that a new container-to-application binding is requested for the container https://orkut.com/container/ and provide a one-time key. The application would then hit https://orkut.com/container/bind and pass back the one-time key and the application URL. The container would return the shared secret. The application could also hit the bind URL without a one-time key in case the shared secret was lost to ask that the exchange be repeated. Now that we have a secret key, every time the application’s box is displayed, the container would pass a a user ID, a unique timestamp and a signature of these values to the client-side of the application (JavaScript). In PHP pseudocode: $sig = md5($userid . $stamp . $secret) . The JavaScript code would pass these along with the request. An impersonator would not be able to generate a valid signature on any user ID other than their own.

Comments

Ramon on

Nice post, I just would like to say that you need to study more to get the concept of OpenSocial. I can tell you it's secure and I'm doing medium complexity applications without any security problem, how can profiles not get cloned? due to unique IDs provided by the OpenSocial to each user. The biggest problem I think is that we are used to plain old user and password type of situation, sort of what private-key means to developers.

What google’s concept is saying: “Hey you are already in my secure container, you worry about the api and I worry about the container.” All of Google’s partners have stopped providing their own containers and will adopt the new SDK as soon as it’s release.

devrandom on

So let's say that someone loads a page where your app is embedded. They then use something like FireBug to modify the user ID from their ID to someone else's. What will your app do? How does your app know that the user ID presented to the back end is not spoofed?

Mat on

Have to say, I agree with devrandom. I currently cant see how you can prevent again spoofing attacks with a javascript only API, Due to the nature of the app we are creating we need to store a substantial amount of data off on our own servers, and we cant store this in any secure maner (e.g. associating it to a certain user), as we cant trust any info coming from the browser. At the moment I cant see a solution to this, but feel free to enlighten me.

Ramon if you could give me the url of your app, maybe a demo could be in order.

Mat

Ramon on

Hi Devrandom and Mat,

Well you can verify if the ID provided is the actual owner of the ID, that’s the first security ‘breach’ solution. Second: Don’t make your application authentication focused, make it owner to friends focused. Third: Implement Ajax calls to verify and/or block any feature you think can be hacked (hijacking, etc.).

Sorry, but I cannot give a url right now due to still on going development but once I get into a beta version I will send you the link. Best, Ramon

devrandom on

Ramon,

You’ll have to provide more details, your comment is not clear to me.

What do you mean by “you can verify the ID …”? There is no functionality in the API to verify IDs.

The second item needs clarification. What kind of application doesn’t care about ID spoofing?

The third item doesn’t make sense, because Ajax is just another way to connect to the back end. It does not provide any additional authentication means.

Thanks.

Tony Stubblebine on

I'd be curious to know how the widget hacks that keep getting reported on TechCrunch are getting closed. It seems like the original Google partners should be sharing their newly learned security best practices.

Hopefully, I’d feel better about the security holes if someone on the Google side acknowledged that they rushed everything in order to get there press releases out and that they were in fact committed to working through these issues publicly.

devrandom on

Google admits to the hole and gives no timeline, here and here (third item down).