> For the complete documentation index, see [llms.txt](https://0xb0b.gitbook.io/writeups/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://0xb0b.gitbook.io/writeups/hack-smarter-labs/2026/implicit.md). # Implicit {% embed url="" %} The following post by 0xb0b is licensed under [CC BY 4.0

](http://creativecommons.org/licenses/by/4.0/?ref=chooser-v1) *** ## 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. {% embed url="" %}

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 {% code overflow="wrap" %} ```python if client_token in valid_tokens: session['username'] = client_username ``` {% endcode %} with something that verifies that the token belongs to the username. {% code overflow="wrap" %} ```python if client_token in valid_tokens and valid_tokens[client_token] == client_username: session['username'] = client_username ``` {% endcode %}

### 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: {% embed url="" %} The following lab deals with the same vulnerability for review: {% embed url="" %}