githubEdit

Access control Vulnerabilities and privilege escalation

Privilege escalation

The types of vulnerabilities that can arise with access control

How to prevent access control vulnerabilities

What is access control

  • Who or what is authorised to perform actions or access resources.

  • In web applications, access control is dependent on authentication and session management.

    • Authentication: confirms that the user is who they say they are.

    • Session management: identifies which subsequent HTTP requests are being made by that same user.

    • Access control: determines whether the user is allowed to carry out the action that they are attempting to perform.

The vulnerability is called Broken access control. Access control design decisions have to be made by humans so the potential for errors is high.

Access control security model

  • These are a set of access control rules that are independent of the technology or implementation platform.

  • These can be implemented within operating systems, networks, database management systems, back office systems, application and web server software.

Programmatic access control

  • The matrix of user privileges is stored in a database or similar.

  • Controls are applied programmatically with reference to this matrix.

  • This includes roles, groups, individual users, collections, workflows.

Discretionary access control (DAC)

  • Access to a resource is based upon users or named groups of users.

  • The owner of the resource or functions can assign or delegate access permissions to users.

  • This model can become very complex to design and manage.

Mandatory access control (MAC)

  • Centrally controlled system of access control.

  • Access to an object (a file or other resource) by a subject is constrained.

  • Users and owners of resources have no capability to delegate or modify access rights.

  • Associated with military clearance-based systems.

Role-based access control (RBAC)

  • Named roles are defined and access privileges are assigned to those roles.

  • Users are then assigned to single or multiple roles.

Vertical access controls

  • Mechanisms restrict access to sensitive functionality to specific types of users.

  • Different user types have access to different application functions:

    • admin = modify / delete any user's account

    • user = read / write

  • Popular in business models to enforce business policies like separation of duties and least privilege.

Horizontal access controls

  • Mechanisms restrict access to resources to specific users.

  • Different users have access to a subset of resources of the same type.

    • Example: a banking application allows a user to view transactions and make payments from their own accounts but not the accounts of other users.

Context-dependent access controls

  • Restrict access to functionality and resources based upon:

    • the state of the application

    • the user's interaction with it.

  • Prevents a user performing actions in the wrong order (e.g., preventing cart modification after payment).

Examples of broken access controls

These exist when a user can access resources or perform actions that they are not supposed to be able to.

1. Vertical privilege escalation

When a user gains access to functionality they are not permitted to access (e.g., a non-administrative user gaining admin access).

Unprotected functionality

  • If the application doesn't enforce protection for sensitive functionality (example: administrator page linked from a user's page).

  • Users can access administrative functions by browsing to the admin URL:

    • https://insecure-website.com/admin

  • Disclosure of administrative URLs in robots.txt:

    • https://insecure-website.com/robots.txt

  • Attackers can use wordlists to brute-force the location of sensitive functionality.

Lab: Unprotected admin functionality

1

Vulnerability

This lab has an unprotected admin panel.

End-goal

Delete user carlos.

Analysis

  • View the robots.txt by appending /robots.txt to the lab URL.

  • Notice the Disallow line discloses the path to the admin panel.

  • In the URL bar, replace /robots.txt with /administrator-panel to load the admin panel.

  • Delete carlos.

Payload

/administrtor-panel

Security by obscurity

  • Sensitive functionality may be concealed by giving it a less predictable URL (e.g., https://insecure-website.com/administrator-panel-yb556).

  • The application might leak the URL in JavaScript that constructs the UI.

This script contains the admin URL for all users regardless of role.

Lab: Unprotected admin functionality with unpredictable URL

1

Vulnerability

This lab has an unprotected admin panel.

End-goal

Delete user carlos.

Analysis

  • Look for disclosures in the application.

  • Review the home page's source using browser dev tools or Burp Suite.

  • Some JavaScript discloses the admin panel URL.

  • Load the admin panel and delete carlos.

Payload

/admin-hpat4k

Parameter-based access control methods

  • Some applications determine a user's access rights or role at login and then store this information in a user-controllable location:

    • hidden field, cookie, or query string parameter.

  • The application makes access control decisions based on the submitted value:

    • https://insecure-website.com/login/home.jsp?admin=true

    • https://insecure-webiste.com/login/home.jsp?role=1

  • By modifying these values, a user can access administrative functions.

Lab: User role controlled by request parameter

1

Vulnerability

The lab has an admin panel at /admin, which identifies administrator using a forgeable cookie.

End-goal

Access the admin panel and delete user carlos. Login credentials: wiener:peter.

Analysis

  • Try /admin and observe you can't access the admin panel.

  • Browse the login page.

  • In Burp Proxy, turn interception on and enable response interception.

  • Complete and submit the login page and forward the result request in Burp.

  • Observe the response sets the cookie Admin=false; change it to Admin=true.

Payload

Open browser inspect tools and change the Admin cookie to true.

Lab: User can be modified in user profile

1

Vulnerability

The lab has an admin panel at /admin, accessible only to logged-in users with roleid of 2.

End-goal

Access the admin panel and delete carlos. Login credentials: wiener:peter.

Analysis

  • Login and access the account page.

  • Update the email associated with your account.

  • Observe the response contains your roleid.

  • Send the email submission request to Burp Repeater and add "roleid":2.

  • The response shows your roleid has changed to 2.

  • Browse to /admin and delete carlos.

Payload

Add the role number to the email parameter and submit to change to admin.

Broken access control resulting from platform misconfiguration

  • Access restrictions based on URLs and HTTP methods may be overridden by non-standard headers like X-Original-URL or X-Rewrite-URL.

  • The front-end may restrict access based on the URL, but the backend may process an overridden URL from headers.

Example attack:

Lab: URL-based access control can be circumvented

1

Vulnerability

This website has an admin panel at /admin. The front end blocks direct access, but the backend supports X-Original-URL.

End-goal

Access the admin panel and delete user carlos.

Analysis

  • Try to load /admin and observe you get blocked (response originates from front-end).

  • Send the request to Burp Repeater.

  • Change the URL in the request line to /.

  • Add header X-Original-URL: /invalid. — the application returns not found, indicating backend processes that header.

  • Change the header to X-Original-URL: /admin.

  • Access admin and delete carlos by adding ?usernme=carlos to the real query string.

  • Optionally change X-Original-URL path to /admin/delete.

Payload

Add header: X-Original-URL: /admin

HTTP method issues: some sites tolerate different HTTP request methods for actions; attackers can switch methods (e.g., GET vs POST) to bypass platform-layer access control.

Lab: Method-based access control can be circumvented

1

Vulnerability

This website implements access control partly based on the HTTP method of requests. Administrator credentials: administrator:admin.

End-goal

Solve the lab by logging in with wiener:peter and exploiting flawed access controls to promote yourself to administrator.

Analysis

  • Log in with admin credentials and browse to the admin panel; promote carlos and send the HTTP request to Burp Repeater.

  • Open a private/incognito window, log in with non-admin credentials.

  • Attempt to re-promote carlos with the non-admin user by copying that user's session cookie into the Burp Repeater request.

  • The response says Unauthorised.

  • Change the method from POST to POSTX — observe the response changes.

  • Convert request to GET and change the username parameter to your username; resend the request.

Payload

Use a low-privilege user's cookie in the request and change the method from POST to GET to bypass method-based checks.

Broken access control resulting from URL-matching discrepancies

  • Inconsistent capitalisation, suffix pattern matching, or trailing slashes can cause endpoints to be matched unexpectedly (e.g., /admin/deleteUser.anything mapping to /admin/deleteUser).

  • Systems may treat /admin/deleteUser and /admin/deleteUser/ differently, allowing bypass via trailing slash.

2. Horizontal privilege escalation

When a user gains access to another user's resources (e.g., by modifying an id parameter).

Note: This is an example of an insecure direct object reference (IDOR)—these arise when user-controlled parameter values are used to access resources or functions directly.

Lab: User ID controlled by request parameter

1

Vulnerability

Horizontal privilege escalation on the user account page.

End-goal

Obtain the API key for user carlos and submit the solution. Login: wiener:peter.

Analysis

  • Log in using the supplied credentials and go to your account page.

  • The URL contains the username in the id parameter.

  • Send the request to Repeater.

  • Change the id parameter to carlos.

  • Retrieve and submit the API key for carlos.

Payload

Change the id parameter to a guessable username.

Note: If the exploitable parameter is not predictable, the app might use GUIDs. Check if GUIDs are disclosed elsewhere in the application (e.g., user messages, reviews).

Lab: User ID controlled by request parameter, with unpredictable user IDs

1

Vulnerability

Horizontal privilege escalation on the user account page where users are identified with GUIDs.

End-goal

Find the GUID for carlos, retrieve his API key, and submit it. Login: wiener:peter.

Analysis

  • Find a blog post by carlos and click his profile—the URL contains his user ID; note it.

  • Login as a normal user.

  • Change the id parameter to the noted carlos user ID.

  • Retrieve and submit the API key.

Payload

Look for GUIDs for other users in the application. Use Burp proxy to intercept requests and supply the stolen user ID.

Note: An application may be misconfigured such that it detects an unauthorized access and redirects to the login page, but the response body may still include some sensitive data.

Lab: User ID controlled by request parameter with data leakage in redirect

1

Vulnerability

The lab leaks sensitive information in the body of a redirect response.

End-goal

Obtain the API key for carlos. Login: wiener:peter.

Analysis

  • Login and go to your account page.

  • Send the request to Burp Repeater and change the id parameter to carlos.

  • The response is redirected to the home page but contains a body with carlos's API key.

Payload

Leaking the API key in the response. Use Burp Repeater to change the user and check the response body.

Horizontal to vertical privilege escalation

  • Attacker compromises a more-privileged user (e.g., an administrator) by targeting their account via parameter tampering or other means.

  • An admin account page might disclose a password or provide means to change it or access privileged functionality.

Lab: User ID controlled by request parameter with password disclosure

1

Vulnerability

The lab's user account page contains the current user's existing password pre-filled in a masked input.

End-goal

Retrieve the administrator's password, use it to delete carlos. Login: wiener:peter.

Analysis

  • Login and access the user account page.

  • Change the id parameter in the URL to administrator.

  • View the response in Burp; it contains the administrator's password.

  • Login to the administrator account and delete carlos.

Payload

Proxy the admin page to reveal the admin password in the response.

Insecure direct object references (IDOR)

  • Occurs when an application uses user-supplied input to access objects directly; an attacker can modify the input to obtain unauthorized access.

Lab: Insecure direct object references

1

Vulnerability

The lab stores user chat logs on the server file system and retrieves them using static URLs.

End-goal

Find the password for user carlos and log into their account.

Analysis

  • Select the live chat tab, send a message, then select View transcript.

  • Review the URL: transcripts are text files with incrementing numbers.

  • Change the filename to 1.txt and review the text; notice a password.

  • Return to the main lab page and login using the stolen credentials.

Payload

Proxy the .txt transcript URL, change the number, and inspect leaked data.

Access control vulnerabilities in multi-step processes

  • Multi-step actions (capture inputs, review, confirm) can be vulnerable if some steps enforce access control and others do not.

  • An attacker can skip steps and directly submit the final request with required parameters.

Lab: Multi-step process with no access control on one step

1

Vulnerability

Admin panel has a flawed multi-step process for changing a user's role. Admin credentials: administrator:admin.

End-goal

Log in as wiener:peter and promote wiener to administrator by exploiting flawed controls.

Analysis

  • Login with admin credentials and promote carlos; send the confirmation HTTP request to Burp Repeater.

  • Login with non-admin credentials.

  • Copy the non-admin user's session cookie into the Repeater request.

  • Change the username to yours and replay the request.

Payload

Replace the session cookie of a high-privileged user on the final confirmation step with a less-privileged user's session, and complete the process.

Referer-based access control

  • Some applications base access control on the Referer header for subpages.

  • The Referer header can be fully controlled by an attacker; forging it can allow direct requests to sensitive subpages.

Lab: Referer-based access control

1

Vulnerability

The lab controls admin functionality based on the Referer header. Admin credentials: administrator:admin.

End-goal

Log in as wiener:peter and promote wiener to administrator.

Analysis

  • Login with admin credentials, promote carlos, and send the HTTP request to Burp Repeater.

  • Login with non-admin credentials.

  • Browse to /admin-roles?username=carlos&action=upgrade — the request is unauthorized due to missing Referer.

  • Copy the non-admin user's session cookie into the Repeater request.

  • Change the username to yours and replay the request.

Payload

Change the Referer header to the one used by admin to appear as if the request came from the admin interface.

Location-based access control

  • Some websites enforce access controls based on geographic location (e.g., banking, media services).

  • These can be circumvented using web proxies, VPNs, or manipulation of client-side geolocation.

How to prevent access control vulnerabilities

circle-check