From User to Admin: The Art of Privilege Escalation

What if I told you that the biggest risk in your web app isn’t hacking the login, but what comes after someone gets in?

Privilege escalation is one of the most powerful weapons attackers use. It’s not about breaking into a system; it’s about taking over. In this blog, we’ll explore how attackers can climb the access ladder in web applications — from a basic user to an all-powerful admin.

What is Privilege Escalation?

When you log in to a web app, your account is given certain permissions. For example:

• A regular user might only be able to view their profile or edit their own data.
• An admin can access everything — user data, settings, and even server configurations.

Privilege escalation happens when an attacker exploits flaws in the app to gain higher-level permissions than they’re supposed to have. This could mean going from a basic user to an admin — or even taking over the entire system.

How Does It Happen?

Privilege escalation in web apps typically happens in two ways:

1. Vertical Privilege Escalation: Moving from a low-level user (e.g., “guest”) to a higher-level role (e.g., “admin”).
2. Horizontal Privilege Escalation: Accessing another user’s data or account without increasing privileges.

Let’s focus on vertical escalation, where attackers aim to gain admin-level access.

Common Privilege Escalation Techniques in Web Apps

1. Insecure Direct Object References (IDOR)

When a web app doesn’t properly check if a user is allowed to access something, attackers can exploit it by changing parameters in the URL or request.

Example:

You’re a regular user and want to view your account details.
The app sends a request:

GET /user/profile?id=123

An attacker changes the id value to another user’s ID (e.g., id=1):

GET /user/profile?id=1

• If the app doesn’t verify permissions, they now see the admin’s profile!

Tools to Exploit IDOR:

• Burp Suite
• Postman

2. Misconfigured Role Checks

Web apps often rely on role-based access control (RBAC) to restrict actions based on user roles (e.g., “user,” “admin”). If these role checks are poorly implemented, attackers can bypass them.

Example:

• The app hides admin features in the user interface but doesn’t block them on the backend.
• An attacker guesses the admin URL:

POST /admin/settings

• If the backend doesn’t check if the user is an admin, the attacker can now make changes meant only for admins.

3. Session Hijacking

Sessions store a user’s login state. If attackers steal an admin session, they can take over their account without even knowing the password.

How Attackers Do It:

• Session Fixation: Tricking an admin into logging in with a session ID the attacker controls.
• Stealing Cookies: Using tools like XSS (Cross-Site Scripting) to grab session cookies.

Example Cookie:

session_id=abc123; role=admin;

If attackers gain access to this, they can impersonate the admin.

4. Exploiting Hidden Fields or Parameters

Sometimes, web apps store important information in hidden fields within forms or requests. If these aren’t validated, attackers can manipulate them.

Example:

• A payment page includes a hidden field:

<input type="hidden" name="user_role" value="user">

An attacker changes it to:

user_role=admin

• If the backend doesn’t verify this, they’ve now escalated privileges.

5. Exploiting Default Credentials

Some apps come with default admin credentials like admin:admin or root:password. If these aren’t changed, attackers can log in and gain instant admin access.

Real-World Example: Privilege Escalation in Action

Scenario:
A company’s web app allows employees to submit expense claims. Admins can approve or reject claims.

What the attacker does:

1. Logs in as a regular employee.
2. Notices that the admin dashboard URL is /admin/dashboard.
3. Sends a request to the admin endpoint:

GET /admin/dashboard

The app doesn’t validate the user’s role, so they gain access to the admin panel and approve fake expense claims.

Tools to Exploit IDOR:

• Burp Suite
• Postman