OAUTH and Javascript

I am surprised to see the careless implementation of OAUTH by almost all providers like Google, Facebook. I am pretty much sure that I might not be the only person who would have noticed it. By this time there could be atleast thousands of botnets which impersonate as a regular site and spam users' walls or create a social network graph as good as facebook. Probably there will be a separate Real Time Bidding auction by the impersonators. In short OAUTH+Javascript is like locking your door and leaving the key under your doormat.

Lets discuss about the differences between the client based OAUTH flow and server based OAUTH flow

• As per Google's documentation, the server loads the page on client(browser) with the app id(public name). 
• On initiating OAUTH with Google servers, the appid and redirection_uri is passed. The Google server calls the redirection_uri with a code.
• The app's server has to cross check the code with client_secret to get the access_token which has the required permissions.

This flow seems foolproof as the trusted authority gets the permission. In a client only app, client_secret is impossible to be used. So that part is removed from the flow. So the flow is,

• The server loads the page on client(browser) with the app id(public name). 
• On initiating OAUTH with Google servers, the appid and redirection_uri is passed. The Google server calls the redirection_uri with the access_token if the referrer and app-id matches.

Thats it now this access_token can be used to post on walls or get profile information. Same is the case with facebook.

Lets discuss how this Javascript feature affects the end users and the third party app developers.

End Users:

This has opened a huge door for phishing on end users. A virus could change etc/hosts or a compromised machine can do a man in the middle attack and direct an end user to a fake website. This website will have same client_id as the original website. Now they can get all accesses the original website(trusted) is supposed to get. Now they are free to spam on the end user's wall if the original app has requested for grant of that permission. They can even access the whole profile data of the user.

Some examples

This site impersonating as digg.com and gets all my profile details.  It actually runs on my local web server

The second one shows  a wall post by the fake Quora App 

As an end user its better to trust OAUTH only on sites which support HTTPS, as it verifies the authenticity of the server we are talking to. Though there are other ways an app can make itself secure from such compromises, but they are difficult for a naive user to test. Don't use OAUTH if the app is not HTTPS. So using OAUTH in Quora(in the above case, I neglected the HTTPS warning given by my browser) is much safer than using OAUTH in digg.

App Developer:

App Developer should make sure that their app is HTTPS so that the users can have a trust that they are talking to the actual person. Facebook has provided some options in their Advanced Configurations like

1. Client OAuth Login
2. Embedded browser OAuth Login
3. App Secret Proof for Server API calls

Setting options for these features appropriately can make the app secure. But as far as I see, even apps from Quora, digg, flipkart have not set these features properly. The above options disable client based OAUTH completely.

So the solution to the problem is to use only HTTPS if you use client based OAUTH or set the above features properly so that javascript based OAUTH is disabled.

OAUTH Provider:

OAUTH providers should understand the sensitivity of the permissions they are going to give to the app and make sure the app is not a spoofed one. Using Client_Secret is the only way to make this possible. But Facebook and Google have brushed off their responsibilities on contacting them, stating its the responsibility of app developer to make things secure

Quoting Google

"I forwarded your report to the engineers working on OAuth, but as you noticed, this is not really a vulnerability but rather a consequence of how OAuth is designed and the fact that the Web has not fully moved to HTTPS."

Quoting Facebook

"Thanks for writing in. We provide application developers with the opportunity to specify a whitelist of valid URIs for redirection on OAuth. If an application does not specify such a whitelist, we allow the request to be sent to any domain that the application has authorized, which also means the request can be made to the HTTP version of the site. We allow redirects to HTTP in general because not all applications on our platform have full support for SSL. The behavior you're describing is caused by the configuration of individual applications"

But OAUTH as a protocol is secure with client_secret. It has been compromised as a trade off for javascript implementation. Security should not be compromised for comfort.