Authentication bypass via flawed state machine
Understanding the Vulnerability
This vulnerability demonstrates a serious flaw in session state management and workflow enforcement, where the application incorrectly assigns privileges when an expected intermediate step is skipped. Instead of securely requiring completion of the role-selection process, the backend mishandles incomplete session states and grants elevated access by default.
This type of vulnerability can lead to privilege escalation, allowing a normal authenticated user to gain unauthorized administrator access without exploiting traditional issues such as SQL injection or broken passwords.
Step 1: User Logs In Normally
The attack starts with a legitimate login attempt using valid credentials.
The user submits a request like:
POST /login
At this stage, the application verifies the username and password successfully.
However, instead of immediately taking the user to the dashboard, the application triggers an additional step before finalizing the session.
Step 2: Backend Requests Role Selection
After authentication succeeds, the backend responds with a redirect or request to a role-selection endpoint:
GET /role-selector
This page is intended to allow the user to select which role they want to assume in the session.
Examples could include:
- Standard user
- Support staff
- Administrator
At this point, the session is only partially initialized.
The user is authenticated, but the role has not yet been assigned.
This is why trying to access privileged pages such as:
/admin
directly from the role selection page does not work.
Step 3: Intercept the Role-Selector Request
Using Burp Suite Proxy, the attacker intercepts the request before it reaches the browser.
The intercepted request looks like:
GET /role-selector
Instead of forwarding it, the attacker drops the request.
This prevents the role-selection page from loading and stops the workflow before completion.
At this point:
- The user is authenticated
- No role has been explicitly selected
- The session is incomplete
A secure application should now:
- invalidate the session
- redirect back to role selection
- deny access to all protected pages
But this application does not.
Step 4: Manually Request the Home Page
After dropping the role-selector request, the attacker manually browses to the application’s main page.
Example request:
GET /
and forwards it.
This is where the vulnerability occurs.
Instead of checking whether the role-selection process was completed, the backend assumes the session is valid.
Step 5: Application Defaults to Administrator
Because the role value was never set, the backend falls back to an insecure default.
Instead of assigning:
user
or:
guest
it assigns:
administrator
This causes the session to inherit full administrative privileges.
Now the attacker can access:
/admin
without ever selecting or being authorized for that role.
The admin panel appears immediately.
Why This Happens Technically
This likely happens because the application uses weak session handling.
For example, after login:
{
"authenticated": true,
"role": null
}
The /role-selector request should update it to:
{
"authenticated": true,
"role": "user"
}
or:
{
"authenticated": true,
"role": "administrator"
}
But because the request was dropped, the role remains null.
The backend may contain flawed logic like:
if session["role"] is None:
session["role"] = "administrator"
This is an unsafe fallback.
Impact of the Vulnerability
Once administrative access is granted, the attacker can:
- delete users
- modify settings
- access sensitive data
- perform administrative actions
In this case, deleting the user “carlos” solves the lab.
In real-world applications, this could result in:
- data breaches
- account takeovers
- service disruption
- financial damage
Root Cause
The vulnerability exists because of three major issues:
1. Insufficient Workflow Validation
The server does not enforce the full authentication process.
It assumes the user completed role selection.
2. Weak Session State Handling
The application allows incomplete session states to continue.
3. Insecure Default Privileges
The application defaults to administrator instead of least privilege.
How to Fix It
A secure implementation should:
Enforce Workflow Server-Side
After login:
{
"authenticated": true,
"role_selected": false
}
Protected resources should verify:
if not session["role_selected"]:
redirect("/role-selector")
Use Least Privilege Defaults
If role is missing:
role = "guest"
never:
role = "administrator"
Validate Every Request
Every protected page should verify authorization before rendering.
Example:
if session["role"] != "administrator":
deny_access()
Key Takeaway
This vulnerability shows why incomplete workflows must fail securely.
If an attacker can manipulate or skip requests in the authentication process, poor session handling and insecure defaults can lead to full privilege escalation.
The application should treat every step in the authentication and authorization process as mandatory and verify it server-side.
Otherwise, simply dropping one request can turn a normal user into an administrator.
Comments