Location Research Breakthrough Possible @S-Logix pro@slogix.in

Office Address

Social List

Detecting Broken Object-Level Authorization Attacks Against OWASP crAPI REST Endpoints Through Server-Side Object Authorization Validation

Description

Modern application environments rely heavily on APIs to provide controlled access to application resources and business functions. APIs may expose user-specific resources, account information, transactions, orders, and other application objects. Improper authorization at the object level can allow an authenticated user to access resources that belong to another user

In this use case, OWASP crAPI (Completely Ridiculous API) is deployed as the controlled API application on an Ubuntu virtual machine. The application provides an intentionally vulnerable API environment that can be used to safely reproduce and validate API authorization weaknesses

A controlled Broken Object-Level Authorization (BOLA) attack is performed from Kali Linux against the laboratory API environment. The attacker authenticates as a legitimate test user and identifies API requests that contain object-level resource identifiers. The resource identifier is manipulated while maintaining the valid authentication context to determine whether the API performs appropriate authorization validation.

Burp Suite Community Edition is used to intercept, modify, and replay API requests during the security assessment. OWASP ZAP is used as an additional API security assessment and validation tool.

The API behavior is analyzed to determine whether the server verifies the authenticated user's authorization to access the requested object. If unauthorized object access is possible, the behavior is identified as a Broken Object-Level Authorization vulnerability.

The proposed solution implements server-side object-level authorization validation. The server verifies the authenticated user's identity, resource ownership, and access permission before allowing protected object operations.

After implementing the defensive mechanism, the same controlled security test is repeated to verify that unauthorized object access is prevented while legitimate users retain access to their authorized resources.

Existing Security Problem

Application: OWASP crAPI REST API

OWASP crAPI is used as the controlled API application for reproducing and validating API authorization vulnerabilities. The application contains authenticated users and user-associated resources, allowing object-level authorization behavior to be assessed under controlled conditions.

The API may correctly authenticate a user but fail to determine whether that authenticated user has permission to access the specific object requested through an API endpoint. Object identifiers are often supplied as part of API requests. If the server trusts these identifiers without performing an authorization check against the authenticated user's permissions, an attacker may manipulate the identifier to request another user's resource.

Existing Problem:

The API may correctly authenticate a user but fail to determine whether that authenticated user has permission to access the specific object requested through an API endpoint.

The security problem is therefore:

OWASP crAPI REST API → Insufficient Object-Level Authorization → Authenticated User Manipulates Object Identifier → Unauthorized Cross-User Object Access → Sensitive Resource Disclosure / Modification → BOLA Security Risk

The proposed solution introduces server-side object-level authorization enforcement to ensure that every protected object operation is evaluated against the authenticated user's permissions.

Attack

Specific Attack: Broken Object-Level Authorization

Broken Object-Level Authorization (BOLA) is an API authorization vulnerability in which an application fails to properly enforce access control for individual resources or objects.

The attacker uses a legitimate authenticated account and manipulates the object identifier associated with an API request. The attack does not require authentication bypass when valid credentials or an authenticated session are already available.

Attack Behavior:
Authenticated Test User
→
Normal API Authentication
→
Protected API Request
→
Identification of Object Identifier
→
Object Identifier Manipulation
→
Modified API Request
→
Server-Side Authorization Validation
→
Authorization Failure Not Enforced
→
Unauthorized Object Access

Security Concept

Object-Level Authorization:

Object-level authorization is the security concept of determining whether an authenticated user has permission to access a specific application resource.

The authorization decision must consider the identity of the authenticated user and the permissions associated with the requested object.

The secure processing flow is:

User Identity
→
Requested Object
→
Permission Validation
→
Access Decision

Defensive Mechanism

External Entity Resolution Blocking

The XML parser is configured so that external entities cannot be resolved.

Purpose

Prevent attacker-controlled XML from causing the server to access external resources.

DTD Processing Restriction

The application restricts or disables DTD processing when DTD functionality is not required.

Purpose

Prevent XML documents from defining external entities that could be processed by the parser.

Secure XML Parser Configuration

The XML parser is configured using security-focused settings rather than relying on default parser behavior.

Purpose

Ensure unsafe XML processing features are explicitly disabled.

Entity Expansion Control

The application restricts excessive entity expansion.

Purpose

Prevent malicious XML documents from causing abnormal parser resource consumption.

XML Input Validation

Incoming XML is validated according to the application's expected XML structure.

Purpose

Reject XML content that does not conform to the permitted application format.

Outbound Network Restriction

The XML API server is prevented from making unnecessary outbound connections.

Purpose

Provide an additional security layer if an application-level validation control is bypassed.

Security Logging

XML parser errors and rejected XML security-policy violations are recorded.

Purpose

Provide visibility into attempted XXE activity and support investigation

Security Tools

Primary XXE Testing Tool: XXEinjector

XXEinjector is used as the primary security-testing tool because it is specifically designed to automate XXE testing.

Purpose
  • Test XML endpoints for XXE behavior.
  • Inject controlled XML entity payloads.
  • Assess external entity processing.
  • Identify XML parser weaknesses.
  • Validate whether external entity resolution is possible.
  • Repeat the assessment after remediation.

Target Application: Controlled XML API

The controlled XML API provides the target environment.

Purpose
  • Receive XML requests.
  • Parse XML input.
  • Process XML-based API operations.
  • Apply secure XML parser controls.
  • Generate application security logs.

Server Environment: Ubuntu

Ubuntu hosts the XML API.

Purpose
  • Run the API application.
  • Configure the XML parser.
  • Implement network restrictions.
  • Maintain application logs.

Container Platform: Docker

Docker is used to deploy the XML API.

Purpose
  • Isolate the application.
  • Provide a reproducible testing environment.
  • Simplify application deployment and reset.

Security Testing Environment: Kali Linux

Kali Linux is used as the security-testing environment.

Purpose
  • Run XXEinjector.
  • Generate controlled XXE assessment requests.
  • Analyze API responses.
  • Perform post-remediation validation.

Process

STEP 01

Step 1: Prepare the Virtualized API Security Environment

  • Create an isolated cybersecurity laboratory using VirtualBox.
  • Configure Ubuntu as the application/server environment.
  • Configure Kali Linux as the security-testing environment.
  • Configure the virtual network for communication between the two virtual machines.
  • Verify connectivity between Kali Linux and Ubuntu.
  • Confirm that the testing machine can reach the API server.
Tools: VirtualBox + Ubuntu + Kali Linux
STEP 02

Step 2: Deploy the OWASP crAPI Application

  • Install and configure Docker on Ubuntu.
  • Deploy OWASP crAPI using its Docker deployment configuration.
  • Start the required crAPI application components.
  • Verify that all required services are operational.
  • Confirm that the API is accessible from Kali Linux.
  • Verify normal application functionality before security testing.
Tools: Ubuntu + Docker + OWASP crAPI
STEP 03

Step 3: Configure the Controlled API Environment

  • Create multiple controlled test users within OWASP crAPI.
  • Configure separate application resources for the test users.
  • Verify that each test account has valid authentication credentials.
  • Establish resource ownership relationships between the test users and their resources.
  • Confirm that users can access their own authorized application functionality.
  • Record the resource ownership information required for authorization testing.
Tools: OWASP crAPI
STEP 04

Step 4: Establish Normal API Behavior

  • Authenticate using the controlled test accounts.
  • Perform legitimate application operations.
  • Capture the API requests generated during normal resource access.
  • Identify protected API endpoints.
  • Identify the API operations that require object-level authorization.
  • Record normal request and response behavior.
  • Establish the normal API access baseline.
Tools: OWASP crAPI + Burp Suite Community Edition
STEP 05

Step 5: Configure API Traffic Interception

  • Install and configure Burp Suite Community Edition on Kali Linux.
  • Configure the browser or API client to route traffic through Burp Suite.
  • Intercept authenticated API requests.
  • Inspect request methods, endpoints, parameters, authentication information, and responses.
  • Identify client-controlled object identifiers.
  • Select relevant object-level endpoints for authorization testing.
Tools: Kali Linux + Burp Suite Community Edition
STEP 06

Step 6: Perform Controlled BOLA Testing

  • Authenticate using a controlled test account.
  • Capture an authorized request to a protected resource.
  • Identify the object identifier associated with the requested resource.
  • Modify the object identifier while maintaining the authenticated context.
  • Replay the modified request through Burp Suite.
  • Observe the API authorization behavior.
  • Record the resulting response and access decision.
Tools: Kali Linux + Burp Suite Community Edition + OWASP crAPI
STEP 07

Step 7: Confirm the Authorization Vulnerability

  • Repeat the authorization test against the relevant object-level API operations.
  • Test multiple controlled user and resource relationships.
  • Compare authorized access with unauthorized cross-user access.
  • Determine whether the API validates resource ownership or permissions.
  • Record the affected API endpoints and operations.
  • Document the authorization failure and its security impact.
  • Confirm the BOLA condition before beginning remediation.
Tools: Burp Suite Community Edition + OWASP ZAP
STEP 08

Step 8: Perform Additional API Security Assessment

  • Configure OWASP ZAP for the controlled crAPI application.
  • Discover and inspect the API endpoints.
  • Review the API's authorization-related behavior.
  • Identify protected resources and operations requiring access control.
  • Correlate the assessment findings with the manual BOLA testing.
  • Prioritize endpoints requiring server-side authorization enforcement.
Tools: OWASP ZAP + OWASP crAPI
STEP 09

Step 9: Implement Server-Side Object Authorization

  • Modify the API authorization logic on the Ubuntu server.
  • Retrieve the authenticated user's identity from the trusted authentication context.
  • Identify the object requested by the API operation.
  • Retrieve the ownership or permission information associated with the object.
  • Compare the authenticated user's identity with the object's permitted access information.
  • Allow the operation only when the authorization requirement is satisfied.
  • Reject the operation when the authenticated user does not have permission.
  • Apply the authorization validation consistently to all protected object-level operations.
Tools: Ubuntu + OWASP crAPI
STEP 10

Step 10: Implement Unauthorized Access Handling

  • Configure the API to reject unauthorized object-level requests.
  • Prevent protected resource information from being returned after an authorization failure.
  • Prevent unauthorized modification or deletion operations.
  • Return an appropriate authorization response to the requesting client.
  • Record authorization failures in the application security logs.
  • Ensure that authorization failures contain sufficient information for security investigation.
Tools: OWASP crAPI + Ubuntu
STEP 11

Step 11: Re-Test the BOLA Attack After Remediation

  • Authenticate using the same controlled test account used during the vulnerability assessment.
  • Capture the relevant API request using Burp Suite.
  • Perform the same object-level authorization manipulation used during the initial assessment.
  • Replay the modified request against the remediated API.
  • Verify that the server performs the authorization check.
  • Confirm that unauthorized object access is rejected.
  • Compare the post-remediation result with the original vulnerability result.
Tools: Kali Linux + Burp Suite Community Edition + OWASP crAPI
STEP 12

Step 12: Validate Legitimate API Access

  • Authenticate using the authorized test accounts.
  • Access resources for which the authenticated users have permission.
  • Perform legitimate read operations.
  • Perform permitted resource modifications where applicable.
  • Verify that legitimate API requests continue to succeed.
  • Confirm that the authorization control does not interfere with normal application functionality.
  • Verify that only unauthorized cross-user resource access is restricted.
Tools: OWASP crAPI + Burp Suite Community Edition
STEP 13

Step 13: Perform Final API Security Validation

  • Perform a final API assessment using OWASP ZAP.
  • Repeat manual authorization testing using Burp Suite Community Edition.
  • Verify that the previously identified BOLA condition can no longer be reproduced.
  • Confirm that object-level authorization is consistently enforced across the tested endpoints.
  • Verify that unauthorized requests are rejected.
  • Verify that legitimate requests continue to function.
  • Review authorization-failure logs generated by the application.
  • Document the vulnerability discovery, remediation, and validation results.
Tools: OWASP ZAP + Burp Suite Community Edition + OWASP crAPI + Ubuntu

Outcome

  1. The Broken Object-Level Authorization (BOLA) attack is successfully assessed against the controlled OWASP crAPI REST API environment.
  2. The assessment demonstrates the risk of relying on authentication without enforcing authorization at the individual object level.
  3. Object-level authorization weaknesses are successfully identified through controlled security testing.
  4. A controlled BOLA attack simulation is performed by modifying client-controlled object identifiers.
  5. API request interception and security analysis are successfully performed using Burp Suite Community Edition and OWASP ZAP.
  6. Unauthorized attempts to access resources belonging to other users are successfully identified and validated.
  7. Server-side object ownership and permission validation is implemented to enforce proper access control.
  8. Unauthorized API requests are rejected, preventing cross-user resource access.
  9. Legitimate users continue to access their authorized resources without affecting normal application functionality.
  10. Before-and-after security validation confirms that the implemented object-level authorization control effectively mitigates the BOLA vulnerability.
← Previous Project
Project 2 of 5
Next Project →