OAuth Based CSRF: Exploiting The Flaw In Implementation Of State Parameter

Hey there! A few days ago, while doing penetration testing on one of the assets of our client, I came through a scenario that is worth sharing. It was an OAuth based CSRF that help attacker to connect his Facebook account to that of victim causing Account Takeover. So let’s dive into it.

What is OAuth?

Basics first! What is OAuth? OAuth is a way to let one app access certain parts of your account on another app without needing to share your password. For example, if you want to let a photo-editing app use your Instagram photos, OAuth lets you approve this access securely. Instead of giving the photo-editing app your Instagram password, OAuth provides a special key (called an access token) that lets the photo-editing app view and use your photos without ever seeing your password.

How does OAuth Work?

When it comes to OAuth, there are 3 key roles that we need to keep in mind.

Client Application: This is the website or app that wants to use your data.

Resource Owner: This is you, the person who owns the data.

OAuth Service Provider: This is the service that holds your data and allows access to it. They offer the tools (APIs) to handle both authorization and resource access.

Now that we know about the 3 roles present in this mechanism, another thing to keep in mind is that that there are different ways through which OAuth is implemented. These different ways are known as grant types and 2 most important types of grant type are implicit grant type and authorization code grant type

Generally, both of these grant types follow these steps:

1. The client application asks for access to certain user data, stating which grant type it will use and what kind of access is needed.

2. The user logs into the OAuth service and gives their explicit consent for the requested access.

3. The client application receives a unique access token that confirms it has the user’s permission to access the data. The process for obtaining this token can differ based on the grant type.

4. The client application uses this access token to make API requests and retrieve the necessary data from the resource server.

OAuth Based CSRF

Now that we know how OAuth actually works, let’s dive into the PoC about how I was able to perform Account Takeover via OAuth based CSRF.

So firstly, I logged in to site with my first account which would act as attacker’s email and an interface like following appeared

This Login Accounts option caught my attention and upon clicking it, I was able to see following details:

Here! This functionality of connecting Facebook account caught my attention and I thought about testing it.

Now I opened another browser and logged in to my second account and it gave me following interface like following appeared:

Here, upon seeing the connected accounts after clicking “Login Accounts”, none of the accounts were connected.

Now I moved to browser 1 where I had already opened the “Login Accounts” section and clicked on “Connect” button as highlighted in screenshot below:

Upon clicking this button, I was redirected to Facebook’s login page where after entering my credentials, following page was displayed.

Now that you know how OAuth works, in the above picture, Facebook is the OAuth service provider, I am the resource owner as I am the one whose resources are going to be utilized and the vulnerable site acts as client application.

Coming back to the PoC, as soon as I clicked on “Continue as” button, I started intercepting requests. First thing that took place was that Facebook gave a unique access token that confirmed that the vulnerable application has the user’s permission to access the data. Secondly, the client application made a request with this access token to retrieve data from Facebook. This request looked something like following:

In the request above, state parameter acts as the CSRF token but the problem is this state parameter was same for all accounts and was not getting generated dynamically and was same for all accounts. I decoded its value and its value was like following:
{“wt”:”134",”app”:”login”,”connect”:true,”next”:”https:\/\/redacted.com”}

I simply right clicked on the request and clicked on “Copy URL” button as highlighted in screenshot below:

I opened second browser in which I was logged in as victim and in new tab, I pasted the copied link and hit the Enter button and bingo! My Facebook account was attached with my victim’s account as shown in screenshot below:

I logged out from my attacker account in browser 1 and again visited login page and clicked on “Sign In with Facebook” button as highlighted in screenshot below:

I was redirected to Facebook’s login page where I entered my credentials and bingo! I was logged in to victim’s account.

Tip: Whenever you’re testing for OAuth based CSRF, always check whether state parameter is correctly implemented or not. Presence of state parameter doesn’t mean that the site is secure from CSRF.