Skip to content

Broken access control

OWASP

OWASP Web Security Testing Guide 4.2 > 5. Authorization Testing > 5.2. Testing for Bypassing Authorization Schema

ID Link to Hackinglife Link to OWASP Description
5.2 WSTG-ATHZ-02 Testing for Bypassing Authorization Schema - Assess if horizontal or vertical access is possible. - Access to Administrative functions by force browsing (/admin/addUser)

Access control determines whether the user is allowed to carry out the action that they are attempting to perform. In the context of 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.

Types of broken access control:

  • Vertical access control: a regular user can access or perform operations on endpoints reserved to admins.
  • Horizontal access control: a regular user can access resources or perform operations on other users.
  • Context-dependent access control: Context-dependent access controls restrict access to functionality and resources based upon the state of the application or the user's interaction with it. For example, a retail website might prevent users from modifying the contents of their shopping cart after they have made payment.

Exploitation

This is how you usually test these vulnerabilities:

Unprotected functionality

At its most basic, vertical privilege escalation arises where an application does not enforce any protection for sensitive functionality. Example: accessing /admin panel (or a less obvious url for the admin functionality.)

Parameter-based access control methods

When the application makes access control decisions based on a submitted value.

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

This approach is insecure because a user can modify the value and access functionality they're not authorized to, such as administrative functions. In the following example, I'm the user wiener, but I can access to user carlos information by modifying the parameter id in the request:

GET /my-account?id=carlos HTTP/2

For GUID and obfuscated parameters, you can chain a data exposure vulnerability with this. Also, an IDOR.

URL override methods

There are various non-standard HTTP headers that can be used to override the URL in the original request, such as X-Original-URL and X-Rewrite-URL.

If a website uses rigorous front-end controls to restrict access based on the URL, but the application allows the URL to be overridden via a request header, then: 

POST / HTTP/1.1
Host: target.com
X-Original-URL: /admin/deleteUser 
...

URL-matching discrepancies

Websites can vary in how strictly they match the path of an incoming request to a defined endpoint.

  • For example, they may tolerate inconsistent capitalization, so a request to /ADMIN/DELETEUSER may still be mapped to the /admin/deleteUser endpoint. If the access control mechanism is less tolerant, it may treat these as two different endpoints and fail to enforce the correct restrictions as a result.
  • Spring framework with useSuffixPatternMatch option enabled allows paths with an arbitrary file extension to be mapped to an equivalent endpoint with no file extension.
  • On other systems, you may encounter discrepancies in whether /admin/deleteUser and /admin/deleteUser/

IDORS

IDORs occur if an application uses user-supplied input to access objects directly and an attacker can modify the input to obtain unauthorized access.

Abusing Referer Request header

The Referer header can be added to requests by browsers to indicate which page initiated a request.

For example, an application robustly enforces access control over the main administrative page at /admin, but for sub-pages such as /admin/deleteUser only inspects the Referer header. If the Referer header contains the main /admin URL, then the request is allowed.

Other Headers to Consider for location-base control

Often admin panels or administrative related bits of functionality are only accessible to clients on local networks, therefore it may be possible to abuse various proxy or forwarding related HTTP headers to gain access. Some headers and values to test with are:

  • Headers:
    • X-Forwarded-For
    • X-Forward-For
    • X-Remote-IP
    • X-Originating-IP
    • X-Remote-Addr
    • X-Client-IP
  • Values
    • 127.0.0.1 (or anything in the 127.0.0.0/8 or ::1/128 address spaces)
    • localhost
    • Any RFC1918 address:
      • 10.0.0.0/8
      • 172.16.0.0/12
      • 192.168.0.0/16
    • Link local addresses: 169.254.0.0/16
Last update: 2024-05-01
Created: April 30, 2024 20:40:09