In the cybersecurity landscape, complex SQL injections or XSS attacks often steal the spotlight and garner widespread attention. However, behind the scenes, there lies a more insidious and pervasive threat that holds a prime spot on the OWASP Top 10 list: Broken Access Control.

The security of a web application is generally built upon three fundamental pillars. Mixing these up is a recipe for disaster:

  • Authentication: This is the bouncer at the door. It asks, "Who are you?"
  • Session Management: This is your visitor badge. It validates, "Are you still that person?"
  • Access Control: These are your clearance levels within the building. It asks, "Are you allowed to enter here?"

In this article, we will examine how an authenticated user can slip through cracks in access control mechanisms to perform Privilege Escalation, and dive into the techniques behind these vulnerabilities.

Access Control Models: Who Gets What Authority?

Before diving into the vulnerabilities, we need to understand how the system should work under normal conditions. Access controls are typically enforced across three axes:

  • Vertical Controls: Based on hierarchy. An "Admin" should be able to configure the system, while a "Standard User" should only be able to use it.
  • Horizontal Controls: The boundary between peers. I can see my own invoices, but even if we have the same privileges, I shouldn't be able to see yours.
  • Context-Dependent Controls: Restrictions based on the state of the operation. For example, the "Order Successful" page should not be accessible without receiving payment confirmation.

However, this theoretical order can easily be shattered by coding errors and misconfigurations.

1. Vertical Privilege Escalation: "No Need to Be an Admin to Act Like One"

Vertical privilege escalation occurs when a low-privilege user (or attacker) gains access to functions reserved for a role with higher privileges.

A. Unprotected Functionality and "Security by Obscurity"

The most common mistake developers fall into is mistaking obscurity for security. Just because the admin panel link doesn't appear in the user interface (UI) doesn't mean that panel is inaccessible.

For instance, the /admin panel might not be linked to a button. However, an attacker can find the following URL by inspecting the robots.txt file or by performing directory brute-forcing: https://insecure-website.com/administrator-panel-yb556

Worse yet, these "hidden" URLs are sometimes exposed within JavaScript code:

<script>
	var isAdmin = false;
	if (isAdmin) {
		// Even if this code block doesn't run, the URL is visible in the source code
		var adminUrl = 'https://insecure-website.com/administrator-panel-yb556';
	}
</script>

For an attacker, "View Page Source" essentially means finding the map to the admin panel.

B. Parameter-Based Manipulation

Applications sometimes fall into the trap of storing the user's role or privilege on the client-side. This data can be found in cookies, hidden form fields, or URL parameters.

Original Request: GET /home.jsp?role=1

Attacker's Request: GET /home.jsp?role=0 (or admin=true)

If the server accepts this parameter directly instead of re-validating it against the database, the attacker gains administrative privileges in a heartbeat.

C. Platform and Configuration Errors

Sometimes the code is secure, but the server configuration (platform layer) is flawed. For example, a system might restrict actions under /admin. However, some frameworks handle non-standard HTTP headers.

An attacker can use headers like X-Original-URL to bypass access restrictions

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

Here, the front-end sees the request as / (home page) and allows it, but the back-end application processes the X-Original-URL header and executes the admin action. Similarly, controls can be bypassed by sending a GET request to a system that only blocks the POST method (Method Manipulation).

Spring Framework Warning: In systems using the Spring framework, there can sometimes be URL matching inconsistencies. If /admin/deleteUser is blocked, variations like /admin/deleteUser.anything or /admin/deleteUser/ might sometimes bypass the filters.

2. Horizontal Privilege Escalation and IDOR

Horizontal escalation has largely become synonymous with the IDOR (Insecure Direct Object References) vulnerability. The core issue here is the application blindly trusting the input sent by the user when accessing database objects.

The scenario is simple:

The user accesses their profile: https://site.com/user/account?id=1001

The attacker changes the parameter in the URL: id=1002

If the application fails to check "Does the ID 1002 actually belong to the current user?", the attacker views someone else's data.

Not Just Numbers: IDOR doesn't have to be limited to sequential numbers (1, 2, 3…). It can also occur via static files (e.g., chat logs 12144.txt) or predictable GUIDs.

Critical Pivot: Horizontal privilege escalation can turn into vertical escalation. If an attacker uses IDOR to access an administrator's password change page or profile information, they can take over the entire system.

3. Business Logic and Multi-Step Processes

In modern web applications, operations are usually step-by-step:

  • Step 1: Authentication
  • Step 2: Data Input
  • Step 3: Confirmation and Processing

Developers often place strict controls on Step 1 and 2 but assume that anyone arriving at Step 3 has already passed the previous steps.

What happens if an attacker intercepts the traffic (Interception Proxy — e.g., Burp Suite) and sends the Request for Step 3 directly to the server? If the server doesn't ask "Did this user complete Step 2?", the attacker has manipulated the process.

Defense Line: How to Ensure Access Control?

Patching access control vulnerabilities is tough because automated scanners struggle to find logic flaws. Security must begin at the design phase.

  • Deny by Default: Adopt the principle that everything is forbidden, and only what is explicitly allowed is open.
  • Centralized Authority: Access controls should not be coded separately on every page; they should be managed via a centralized library or middleware.
  • Never Trust the Client: Authority checks should never be done based on data coming from the user's browser (cookie, hidden field). Validation must always be performed using server-side session data.
  • Deep Testing: Code Reviews and logical penetration tests must go beyond automated scans.

Conclusion

Access control is the cornerstone of a web application. A broken access control mechanism can render even the strongest encryption methods or the most secure servers moot. Security isn't just about locking the front door; it's about constantly verifying who is allowed to enter which room inside.

None

Halil İbrahim Eroğlu