Write-up: Authentication bypass via OAuth implicit flow @ PortSwigger Academy

Frank Leitner
InfoSec Write-ups
Published in
3 min readAug 30, 2022

--

This write-up for the lab Authentication bypass via OAuth implicit flow is part of my walk-through series for PortSwigger’s Web Security Academy.

Learning path: Advanced topics → OAuth authentication

Python script: script.py

Lab description

Steps

As usual, the first step is to analyze the functionality of the lab application. In this lab, it is a blog system.

The description mentions a flaw in the access control for authenticated functionality, so I log in with the known credentials of wiener.

The login is done via an external identity provider. As a first step I log in, and in a second step I authorize the target application to receive some of my data:

Once I click on Continue, I am logged in to the lab application.

The theory

After I log in, I check the request/response activities of the login feature in the history of Burp Proxy.

The lab name already hints at the implicit flow of OAuth. This approach is insecure as it routes security information via the client, allowing me to manipulate it if no countermeasures against manipulation are included.

The identity provider sends me the authentication token which my client uses to authenticate towards the target application:

If no information about my username is encoded into the token, then using my token and replacing the username and email will be enough to impersonate my victim.

Even in the original RFC for OAuth 2.0, the security issue is mentioned. Unfortunately, in a rather vague manner:

convenience should be weighed against the security implications

This wording does not discourage enough, so in the latest draft it is worded stronger and more direct:

In order to avoid these issues, clients SHOULD NOT use the implicit grant […]

Only time will tell if this is enough…

The malicious payload

I log out of the application, activate intercept in Burp Proxy and re-login. Once the authentication token is intercepted, I change the username and email to my victim.

That way, the token value of my login gets used for the account of my victim, at least if the token does not contain any information about username and/or email:

Manipulation of the authentication request

I forward the request and switch intercept off. Once all redirects are done, the application updates to

Originally published at https://github.com.

New to Medium? Become a Medium member to access all stories on the platform and support me at no extra cost for you!

From Infosec Writeups: A lot is coming up in the Infosec every day that it’s hard to keep up with. Join our weekly newsletter to get all the latest Infosec trends in the form of 5 articles, 4 Threads, 3 videos, 2 Github Repos and tools, and 1 job alert for FREE!

--

--

Tech nerd, doing security stuff for fun and some as a job | CISSP-ISSAP, OSCP