PortSwigger's "Authentication bypass via OAuth implicit flow" Walkthrough

PortSwigger recently added a set of OAuth labs and while most of them are Practitioner and Expert level, one has been created in the Apprentice category at the time of this writing. This lab covers a vulnerability in an “implicit flow” implementation.

For this walkthrough, you’ll need a Portswigger Academy account and Burp Suite set up and configured (blog post on that here). Log in to your Academy account and then view the lab at https://portswigger.net/web-security/oauth/lab-oauth-authentication-bypass-via-oauth-implicit-flow. This is accessible from the “all labs” view or from the OAuth page.

Challenge Information

Click the “Access the Lab” button and you will be taken to a temporary website that is created for your account. This will be in format https://<random string here>.web-security-academy.net/.

OAuth is a method of sign-on and authentication/authorization most commonly seen in the “login with Facebook” or similar buttons.

This lab covers a flaw in the implicit grant type, which is described in detail on this page. Once a token has been issued, the information sent along with it is (often) implicitly trusted, as is the case in this lab.

From this page, the vulnerability is summarized as:

Here’s the website:

If we go to login, we’re greeted with this clunky social sign-in box:

After we provide the known credentials of wiener:peter, we are asked to authorize the website:

Eventually, we’ll be directed back to the site and can view our account.

Inspecting OAuth Traffic

With Burp Suite running for the previous process, the Proxy > HTTP history view shows a lot of traffic for this seemingly simple workflow:

After the /social-login request, there’s a number of interactions with the OAuth server set up for this lab:

The OAuth server will respond to this GET request with the location of the next request the client needs to make. This is how the login form is loaded, and the POST request for our input is created:

Next, we confirm the authorization, and there are a few more requests, ending in a request to /oauth-callback that tells the browser what to do next:

The browser makes a request to /me and gets information back:

It then makes one last POST request, sending the OAuth token we’ve been given, along with the username and email:

This last request, the POST to /authenticate, is where the vulnerability is suspected. The token is certainly checked for validity, but the server might not validate the other info, including the email.

Lab Solution

To test this, right-click on the request in Burp Suite and select Send to Repeater. Then modify the request to use Carlos’ email address carlos@carlos-montoya.net instead.

If we send this request, the response is a 302 instead of a 401 or 403 as we might expect. This means the info was likely accepted as valid.

I could not figure out how to get the lab to be marked as “solved” while remaining solely in Burp Suite.

To solve it, right click on the modified request (in the Repeater view as shown above), and select Request in Browser.

Then copy the URL value:

And open it in your browser to solve the lab: