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




Comments

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
https://www.kernel.org/doc/gorman…

The server, me and the conversation

We were moving a project from AWS to our co-located DC. We have setup KVMs scheduled by Cloudstack for each of the component in the architecture. The KVMs used local storage. The VMs are provisioned with more than required resources because we have the opinion that in our DC scaling during peak load and then downscaling doesn't offer much benefits financially as we are anyways paying for the hardware in advance and its also powered on. Its going to be idle if not used. Now we found something interesting our latency in co-located DC was 2 times more than in AWS. The time for first byte at our load balancer in aws was 60ms average and at our DC was 112ms. We started our debugging mission, Mission Conquer-AWS. All the servers are newer Dell hardwares. So the initially intuition was virtualisation is causing the issue.

Conversation with the Hypervisor We started with CPU optimisation, we started using the host-passthrough mode of CPU in libvirt so VMs dont see QEMU emulated CPUs, the…

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.

De…