Skip to main content

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 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.


Popular posts from this blog

Lessons from Memory

Started debugging an issue where Linux started calling OOM reaper despite tons of memory is used as Linux cached pages. My assumption was if there is a memory pressure, cache should shrink and leave way for the application to use. This is the documented and expected behavior. OOM reaper is called when few number of times page allocation has failed consequently. If for example mysql wants to grow its buffer and it asks for a page allocation and if the page allocation fails repeatedly, kernel invokes oom reaper. OOM reaper won't move out pages, it sleeps for some time and sees if kswapd or a program has freed up caches/application pages. If not it will start doing the dirty job of killing applications and freeing up memory. In our mysql setup, mysql is the application using most of the Used Memory, so no other application can free up memory for mysql to use. Cached pages are stored as 2 lists in Linux kernel viz active and inactive.
More details here…

How we have systematically improved the roads our packets travel to help data imports and exports flourish

This blog post is an account of how we have toiled over the years to improve the throughput of our interDC tunnels. I joined this company around 2012. We were scaling aggressively then. We quickly expanded to 4 DCs with a mixture of AWS and colocation. Our primary DC is connected to all these new DCs via IPSEC tunnels established from SRX. The SRX model we had, had an IPSEC throughput of 350Mbps. Around December 2015 we saturated the SRX. Buying SRX was an option on the table. Buying one with 2Gbps throughput would have cut the story short. The tech team didn't see it happening.

I don't have an answer to the question, "Is it worth spending time in solving a problem if a solution is already available out of box?" This project helped us in improving our critical thinking and in experiencing the theoretical network fundamentals on live traffic, but also caused us quite a bit of fatigue due to management overhead. Cutting short the philosophy, lets jump to the story.


Walking down the Memory Lane!!!

This post is going to be an account of  few trouble-shootings I did recently to combat various I/O sluggishness.
Slow system during problems with backup
We have a NFS mount where we push backups of our database daily. Due to some update to the NFS infra, we started seeing throughput of NFS server drastically affected. During this time we saw general sluggishness in the system during backups. Even ssh logins appeared slower. Some boxes had to be rebooted due to this sluggishness as they were too slow to operate on them. First question we wanted to answer, does NFS keep writing if the server is slow? The slow server applied back pressure by sending small advertised window(TCP) to clients. So clients can't push huge writes if server is affected. Client writes to its page cache. The data from page cache is pushed to server when there is a memory pressure or file close is called. If server is slow, client can easily reach upto dirty_background_ratio set for page cache in sysctl. This di…