Implicit

Challenge Lab (Medium) - by Tyler Ramsbey

CourseStackwww.hacksmarter.org

The following post by 0xb0b is licensed under CC BY 4.0

---

Scenario

Objective #1: Penetration Test

Our engineering team is currently rolling out "HackSmarter ID," a centralized Single Sign-On (SSO) solution designed to provide seamless access across all of our internal platforms. To support lightweight, browser-based applications, the developers have implemented an OAuth-style Implicit Grant flow.

You have been contracted to perform a targeted penetration test against this new integration before it goes live to production.

Objective #2: Secure Code

A critical zero-day vulnerability has been reported in the HackSmarter ID SSO integration, allowing complete account takeover. As the attending Application Security Engineer, you must immediately triage the vulnerable codebase, implement a hot-patch, and deploy the fix via our automated CI/CD pipeline.

You can access the internal Git server at http://[lab-ip]:3000 and log in with these credentials: student:HackSmarter2026!

All changes you make to app.py will automatically be pushed to production. Your tasks is to fix the vuln you discovered (without breaking the app). Verify the fix by attempting to re-exploit the app.

Summary

Summary

In Implicit we conduct a targeted web application assessment against a newly deployed OAuth-style Implicit Grant SSO integration. By intercepting the browser-based authentication flow, we identify a critical logic flaw in the /api/login endpoint: the backend validates only whether an access token exists, but does not verify that the token is bound to the supplied username. By capturing a valid token for a low-privileged user and replaying the request with the username parameter modified to administrator, we successfully achieve full account takeover and administrative access.

Objective #1

Since we are dealing with a web app in this scenario, we will skip the nmap scan for now and focus on the service on port 80. We are dealing with the HackSmarter labs site, where we can log in using a mechanism similar to Oauth.

First, we create an account.

We will now intercept every request and examine it closely. Alternatively, we can also look at the HTTP history. But we want to attack the service directly if we notice anything.

We intercept the log-in request...

and forward the requests until we reach the authorization page. We issue the authorization...

Now we go through each request an see that the access_token and username is issued via /api/login.

As described, we can see that we are dealing with an implicit grant flow - the access token is directly returned und used in the next request.

Implicit grant type

The implicit grant type is much simpler. Rather than first obtaining an authorization code and then exchanging it for an access token, the client application receives the access token immediately after the user gives their consent.

You may be wondering why client applications don't always use the implicit grant type. The answer is relatively simple - it is far less secure. When using the implicit grant type, all communication happens via browser redirects - there is no secure back-channel like in the authorization code flow. This means that the sensitive access token and the user's data are more exposed to potential attacks.

The implicit grant type is more suited to single-page applications and native desktop applications, which cannot easily store the client_secret on the back-end, and therefore, don't benefit as much from using the authorization code grant type.

OAuth grant types | Web Security AcademyWebSecAcademy

Maybe the checks are not strict enough... we try to authenticate as administrator with the token of 0xb0b.

We forward the request, and are able to log in. We capture the flag! The authentication mechanism does not check if the token belongs to the user in the request, but uses the supplied username with the token to create the session.

Objective #2

Fix

To fix the issue we check the app.py in the mentioned repository.

The application only checks if the token exists, but does not verify that the token belongs to the username provided by the client.

At line 103 we need to replace the following if clause

if client_token in valid_tokens:
    session['username'] = client_username

with something that verifies that the token belongs to the username.

if client_token in valid_tokens and valid_tokens[client_token] == client_username:
    session['username'] = client_username

Re-exploit

We repeat the steps from Objective #1 and get now and expired access token error.

Recommendation

To further hone your OAuth skills, I recommend the following resource:

OAuth 2.0 authentication vulnerabilities | Web Security AcademyWebSecAcademy

The following lab deals with the same vulnerability for review:

Lab: Authentication bypass via OAuth implicit flow | Web Security AcademyWebSecAcademy