Hello everyone, in this final installation of the OAuth blog series, we’ll be covering two vulnerabilities in the OAuth implementation. If you haven’t checked out the previous parts you can check out part one here and part two here. Before we get started, a big thanks to PortSwigger and their Web Security Academy Labs!

The first lab show cases the vulnerability of OAuth’s implicit grant permissions.

The second lab shows how a specifically crafted CSRF attack can link an available token with a victim’s account.

First Lab

To achieve this we perform 2 simple steps:

1. We will step through the complete flow with our provided credentials until we reach the /authenticate call.
2. In this authentication call we will change the email address to Carlos’s email address and proceed logging in.

Why Does This Work?

It is because client application doesn’t validate the access token with other parts of the data in the incoming request, simply changing the parameter (in this case the email id) allowed us to impersonate as Carlos.

Second Lab

1. We would first be logging into the application through the Login call available with wiener’s credentials.
2. Next, we will be attempting to attach a social profile, which would be wiener’s but not complete the flow so that we can use the valid access token for our attack (since no account will be associated to it)
3. We intercept this entire request with burp and step through the flow till we reach the /oauth-linking call. We save this URL for later to craft our attack.
4. Once we’ve copied this URL, we’ll be dropping this authentication flow to break it, and maintain an empty access token that will be used to link the admin’s social media credentials to it. [Do not forget to remove the token from the URL when navigating back to the previous page.]
5. We then move to our exploit server to craft a specific iframe packet that will be sent to the administrator. [This scenario assumes that the administrator clicks any link given to him]
6. This crafted packet will require two things, one the ID of your lab. and two the AUTH token we copied earlier.
7. The crafted CSRF payload is delivered to the victim using the deliver exploit to victim call.
8. Once we go in, we can see that we have the option to view the admin panel, which goes to show our exploit worked and are now in control of the admin page.

Why Does This Work?

This particular vulnerability worked due to the lack of state being used by the AUTH flow.

The full video walkthrough for both the labs are published on my former company’s YouTube channel. Do check it out! Apologies for minor audio issues in Lab 2 due to the microphone 🙂

That would be all for the OAuth Series, stay tuned for more content!