Skip links

OWASP API Top 10 – Most Common Attacks and How to Prevent Them – Part I

Jump To Section

owasp top 10 api vulnerabilities

APIs (Application Programming Interfaces) play a vital role in connecting and integrating various software systems. However, as APIs become increasingly prevalent, they also become attractive targets for malicious actors seeking to exploit vulnerabilities. The OWASP (Open Web Application Security Project) API Top 10 vulnerabilities serve as a guide to understanding and addressing the most critical security risks faced by APIs. 

Dive into the Top 10 OWASP API Vulnerabilities of 2023

In this blog, we will explore the first five vulnerabilities on the OWASP API Top 10 list for 2023: Broken Object Level Authorization, Broken Authentication, Broken Object Property Level Authorization, Unrestricted Resource Consumption, and Broken Function Level Authorization. By examining these vulnerabilities, we can gain insights into the potential risks and effective preventive measures to ensure the security and integrity of our API implementations.

The following vulnerable apps were used to demonstrate vulnerabilities for each section:

OWASP – crAPI

https://github.com/OWASP/crAPI

Tools used:


Burpsuite Tool
PostMan Tool
ffuf tool
Hashcat tool

API1:2023 – Broken Object Level Authorization

API endpoints vulnerable to broken object-level authorization provide an opportunity for attackers to manipulate object IDs within the request. Object IDs can take various forms, such as sequential integers, universally unique identifiers (UUIDs), or generic strings, and are often exposed in the request target, headers, or payload.

This vulnerability is prevalent in API-driven applications where the server relies on client-provided parameters like object IDs to determine which objects should be accessed. Instead of maintaining comprehensive client state, the server relies on the success or failure of the request’s response to gauge authorization.

Implications and Risks:

Exploiting broken object-level authorization can have severe repercussions, including:

Unauthorized Data Disclosure: Attackers can gain unauthorized access to sensitive data by manipulating object IDs. This can lead to the exposure of confidential information, undermining data privacy and compliance requirements.

Data Loss and Tampering: Unauthorized access to objects can enable attackers to modify or delete data, leading to data loss or manipulation. This can disrupt business operations, compromise data integrity, and impact the reliability of the API-driven system.

Account Compromise: In certain scenarios, broken object-level authorization can result in complete account compromise. Attackers can leverage unauthorized access to escalate privileges, gain control over user accounts, and potentially impersonate legitimate users.

Example with crAPI:

I created a user and a confirmation email was sent to localhost:8025

Owasp api top 10

I added the vehicle to my dashboard with the vehicle info:

Vehicle Details Owasp API
image 2

Enter information into the form.

Vehicle Details Owasp API

Go to HTTP history and check the POST request.

Vehicle Details Owasp crAPI

In the response, paste the report_link URL into the web browser:

HTTP History check

We can see information on our vehicle here:

Report Link URL

Changing the id value to 5, will allow us to see another vehicle in the system that is owned by someone else.

Information on our vehicle

To protect API endpoints against broken object-level authorization vulnerabilities, consider implementing the following measures:

  1. Implement Proper Authorization Checks: Implement robust authorization mechanisms to ensure that only authorized users can access specific objects. Use strong authentication and enforce access controls based on user roles and permissions.
  2. Verify Object Ownership: Verify that the requesting user has appropriate ownership or access rights to the targeted object before allowing any operations.
  3. Employ Role-Based Access Control (RBAC): Implement RBAC to manage access control based on predefined roles, ensuring that users only have access to the objects and functionalities relevant to their assigned roles.
  4. Input Validation and Sanitization: Validate and sanitize all user input, especially object IDs, to prevent injection attacks or unauthorized manipulation of identifiers.
  5. Monitor and Detect Suspicious Activities: Implement robust logging and monitoring mechanisms to identify abnormal or unauthorized access attempts. Continuously monitor API traffic, detect patterns of unauthorized object access, and trigger alerts for suspicious activities.
  6. Regular Security Assessments: Conduct regular security assessments, including penetration testing and code reviews, to identify and address any weaknesses or vulnerabilities in the authorization process.

API2:2023 Broken Authentication

Authentication mechanisms that are implemented incorrectly or contain flaws create opportunities for attackers to compromise authentication tokens or exploit vulnerabilities to assume the identities of other users. The consequences of broken authentication extend beyond individual user accounts, as the overall security of the API ecosystem becomes compromised.

Attackers are attracted to authentication vulnerabilities due to the widespread exposure of these mechanisms to all users. Even attackers with limited technical skills can leverage readily available tools to exploit authentication issues, increasing the potential for successful attacks.

Exploiting broken authentication can grant attackers complete control over other users’ accounts, enabling unauthorized access to personal data and the ability to perform sensitive actions on their behalf. The challenge for systems lies in distinguishing the actions of an attacker from those of a legitimate user, making it crucial to implement robust security measures to mitigate these risks.

Also read: Enhancing Cybersecurity Defenses: An Introduction to iCAST

Attack Demonstration – hashcat:

Here is an example of a JWT token with a very weak secret that can be easily bruteforced by a wordlist. We will run the following command to crack the secret of this JWT token:

hashcat -a 0 -m 16500 eyJhbGciOiJIUzI1NiJ9.eyIzNDM2MzQyMCI6NTc2ODc1NDd9.f1nXZ3V_Hrr6ee-AFCTLaHRnrkiKmio2t3JqwL32guY /usr/share/wordlists/rockyou.txt

vehicle in the system

Secure against broken authentication: Best practices:

  1. Secure Password Policies: Enforce strong password policies, including requirements for complexity, length, and periodic password changes. Encourage users to utilize unique and complex passwords.
  2. Multi-Factor Authentication (MFA): Implement MFA to add an extra layer of security beyond passwords. This can include factors such as one-time passwords (OTP), biometrics, or hardware tokens.
  3. Session Management: Implement secure session management techniques, including secure session tokens, token expiration, and proper logout functionality. Use secure transport protocols, such as HTTPS, to protect the transmission of session tokens.
  4. Regular Security Patching: Keep authentication mechanisms and related software up to date with the latest security patches to address known vulnerabilities.
  5. Account Lockout Mechanisms: Implement mechanisms to lock user accounts temporarily after a certain number of failed login attempts to mitigate brute-force attacks.
  6. User Account Monitoring: Monitor user accounts for suspicious activities, such as multiple failed login attempts or concurrent sessions from different locations. Implement automated alerts for potential unauthorized access.
  7. Security Testing and Code Reviews: Conduct regular security testing, including penetration testing and code reviews, to identify and address authentication vulnerabilities. This includes testing for common issues like weak password storage, predictable session IDs, and insecure authentication protocols.

API3:2023 Broken Object Property Level Authorization

Broken Object Property Level Authorization refers to the lack of proper authorization validation at the granular object property level within an API. APIs often expose endpoints that return all properties of an object, especially in the case of REST APIs. For protocols like GraphQL, specific requests may need to be crafted to specify the properties to be returned. While identifying and manipulating these properties may require some effort, there are readily available automated tools that can assist in this process.

By inspecting API responses, attackers can identify sensitive information inadvertently exposed in the representations of returned objects. Fuzzing techniques are commonly used to uncover additional, hidden properties that may reveal further insights. Determining whether these properties can be modified involves crafting API requests and analyzing the corresponding responses. In certain cases, side-effect analysis may be necessary if the desired property is not directly returned in the API response.

This category is a convergence of API3:2019 Excessive Data Exposure and API6:2019 – Mass Assignment, with a primary emphasis on the root cause: the absence or inadequate authorization validation at the object property level. As a result, sensitive information becomes vulnerable to exposure or manipulation by unauthorized entities.

Attack Demonstration – crAPI:

Note: To find parameters to exploit for mass assignment, we can use decoded JWT tokens, source code and other sources to find that out.

Use the user credentials you created earlier to login.

Go to the /shop endpoint on burp proxy browser.

Authentication Vulnerabilities

Go to HTTP history and send the following API to Burp Intruder module.

Burp Proxy Browser

Going to fuzz the request type:

API to Burp Intruder module

Use the following wordlist:

  • GET
  • POST
  • PUT
  • DELETE
  • HEAD
  • OPTIONS
  • TRACE
  • CONNECT
  • PATCH

Run the wordlist with Intruder and get the following results:

fuzz the request type

GET request shows several items being displayed on the screen:

Intruder attack OWASP

But POST request seems to give us an interesting error:

GET request OWASP API

Convert the repeater request into JSON:

POST request OWASP API

We can see this is converted into JSON:

Repeater request into JSON

We’re going to send the following information:

Converted into JSON

{“name”:”applecake”, 

“price”:”-500″,

“image_url”:”http://localhost:8888/images/seat.svg”}

We get a 200 response after sending the request:

Request Send OWASP API

Going back to the /shop endpoint, we can see the new item added to the shop.

200 response OWASP API

Hit the buy button for the applecake item worth -$500

buy button CrAPI
Past Orders crAPI

Go back to the /shop page and look at your available balance. You will now see that it has increased from $100 to $500.

Past Orders crAPI
  1. Implement Fine-Grained Authorization: Apply authorization checks at the object property level to ensure that only authorized users have access to specific properties. Restrict access to sensitive properties based on user roles and permissions.
  2. Conduct Comprehensive Input Validation: Validate and sanitize all user input to prevent injection attacks or unauthorized manipulation of object properties. Apply input validation techniques to both client-supplied and server-generated properties.
  3. Limit Exposed Object Properties: Design API endpoints to return only the necessary properties, avoiding the exposure of sensitive or unnecessary information. Employ techniques such as data masking or redaction for sensitive data within API responses.
  4. Leverage Automated Security Testing: Regularly perform automated security testing, including fuzzing and vulnerability scanning, to identify potential issues related to broken object property level authorization. These tests can help uncover hidden or unintended property exposures.
  5. Implement Logging and Monitoring: Implement robust logging and monitoring mechanisms to detect and track unauthorized access attempts or modifications to object properties. Analyze logs and monitor for suspicious activities that may indicate potential unauthorized access.
  6. Regular Security Assessments: Conduct regular security assessments, including penetration testing and code reviews, to identify and address vulnerabilities related to broken object property level authorization.

API4:2023 – Unrestricted Resource Consumption

APIs are powered by various resources, including network bandwidth, CPU, memory, storage, and even services like emails, SMS, phone calls, or biometrics validation. These resources are typically provided by service providers via API integrations and are billed on a per-request basis. Unrestricted resource consumption occurs when APIs fail to impose limits on client interactions or resource utilization, leaving them vulnerable to exploitation.

Attackers can initiate simple API requests to consume resources maliciously, leading to two primary consequences:

  1. Denial of Service (DoS): By bombarding an API with a high volume of concurrent requests, attackers can overwhelm the system, causing it to become unresponsive or unavailable for legitimate users. This can disrupt essential services and impact user experience.
  2. Increased Operational Costs: Unrestricted resource consumption can result in significant operational costs for API providers. Attackers can exploit APIs to exhaust resources such as CPU, memory, storage, or other services, leading to increased expenses related to infrastructure, cloud storage needs, or usage-based service models.

Attack Demonstration – crAPI:

Click on forgot password in the login page:

Shop Page OWASP API

Enter an email you created earlier:

Attack Demonstration crAPI

In the email server you’ll get an OTP to help you reset the password, but we don’t want to do that. We want to password brute force it.

Email Creater

We can easily do this on burp pro by sending it to intruder and setting the payload to a 4 digit number. However, we will be using FFUF to automate a bruteforce attack on the app.

Set these parameters and send so we can get the HTTP request in burp http history:

Email OTP

It will say invalid but that’s ok:

Say Email OTP Owasp API

Copy this request over to a .txt file:

Proxy File

Save as request.txt – replace the OTP parameter with FUZZ

POST /identity/api/auth/v2/check-otp HTTP/1.1

Host: localhost:8888

Content-Length: 75

sec-ch-ua: “Not:A-Brand”;v=”99″, “Chromium”;v=”112″

sec-ch-ua-platform: “Linux”

sec-ch-ua-mobile: ?0

User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/112.0.5615.138 Safari/537.36

Content-Type: application/json

Accept: */*

Origin: http://localhost:8888

Sec-Fetch-Site: same-origin

Sec-Fetch-Mode: cors

Sec-Fetch-Dest: empty

Referer: http://localhost:8888/forgot-password

Accept-Encoding: gzip, deflate

Accept-Language: en-US,en;q=0.9

Connection: close

{“email”:”hacker@hacker.com”,”otp”:”FUZZ”,”password”:”Password@!1“}

Now run the following command in FFUF:

ffuf -request request.txt -request-proto http -w /usr/share/seclists/Fuzzing/4-digits-0000-9999.txt -mc 200

protect APIs

To protect APIs from unrestricted resource consumption attacks, consider the following:

  1. Rate Limiting: Set limits on the number of requests allowed from individual clients within a specific timeframe. This helps prevent excessive resource utilization caused by malicious actors.
  2. Monitoring and Anomaly Detection: Employ robust monitoring solutions to track API traffic, resource utilization, and patterns of abnormal behavior. Implement anomaly detection mechanisms to identify suspicious resource consumption patterns.
  3. Implement API Throttling: Introduce mechanisms to control and limit the rate of API requests from clients, ensuring that the overall resource consumption remains within acceptable boundaries.
  4. Validate and Sanitize User Input: Implement strict input validation to prevent attackers from injecting malicious code or parameters that manipulate resource usage.
  5. Regular Security Assessments: Conduct regular security assessments, including vulnerability scans and penetration tests, to identify and address any potential weaknesses in API security.

API5:2023 Broken Function Level Authorization

APIs often employ complex access control policies that involve hierarchies, groups, roles, and varying levels of administrative and regular functions. However, when the implementation of these policies is flawed or unclear, it creates an opportunity for attackers to exploit authorization flaws.

Exploitation of Broken Function Level Authorization typically involves sending legitimate API calls to an API endpoint that should be restricted to anonymous or non-privileged users. Attackers target exposed endpoints, taking advantage of misconfiguration or improper authorization checks.

The Challenge of Implementing Proper Authorization: Authorization checks for functions or resources are typically managed through configuration or code. However, implementing robust and accurate authorization checks can be a complex task due to the presence of multiple roles, groups, and intricate user hierarchies within modern applications. For example, sub-users or users with multiple roles can further complicate the authorization process.

APIs, with their structured nature and predictable access patterns, become easier targets for identifying and exploiting these flaws compared to other parts of an application.

Attack Demonstration – crAPI:

Create a profile or use the one from previous demo, we will click on the three dots under My Personal Video to open the file upload feature:

Profile

Upload any .mp4 video to your profile:

Edit My Profile

Go to the Burp Suite Proxy HTTP History and note the ID of the response which is 30 for our current user:

Burp Suite Proxy HTTP History

Create another user and upload any video – can be the same as the previous one. Capture the request and add into Postman:

Upload any video

Notice the ID is 32.

When we attempt to delete this we will get a response saying this is an admin function: 

Capture the request

We can use the example above, to modify it to localhost:8888/identity/api/v2/admin/videos/32 and see if we can delete the video.

Oftentimes, using an older version of the API, in this example going from v3 to v2 and adding an “admin” endpoint can often result in finding a deprecated API that wasn’t meant to be exposed publicly.

If we try this again, we can see that the file was deleted successfully, even though the user wasn’t an admin.

Broken Function Level Authorization vulnerabilities

To protect against Broken Function Level Authorization vulnerabilities, consider the following:

  1. Implement Secure Access Controls: Ensure proper access controls are in place, with well-defined roles, groups, and hierarchies. Regularly review and update these controls as the application evolves.
  2. Principle of Least Privilege: Apply the principle of least privilege, granting users only the permissions necessary for their specific functions or roles.
  3. Role-Based Access Control (RBAC): Implement RBAC to manage access to functions and resources based on predefined roles. Regularly review and update role assignments as needed.
  4. Robust Authorization Checks: Implement strong authorization checks at both the code and configuration levels to ensure that users are granted access only to the appropriate functions and resources.
  5. Regular Security Assessments: Conduct regular security assessments, including code reviews and penetration testing, to identify potential flaws in the authorization process and address them promptly.
  6. Security Training and Awareness: Educate developers and system administrators about the importance of proper authorization practices and the risks associated with Broken Function Level Authorization.

Conclusion

APIs play a crucial role in modern software systems, but their widespread adoption has made them attractive targets for cyber attackers seeking to exploit vulnerabilities. The OWASP API Top 10 vulnerabilities provide a comprehensive guide to understanding and mitigating the most critical security risks faced by APIs.

In this blog, we have delved into the first five vulnerabilities on the OWASP API Top 10 list for 2023, namely Broken Object Level Authorization, Broken Authentication, Broken Object Property Level Authorization, Unrestricted Resource Consumption, and Broken Function Level Authorization. By exploring these vulnerabilities, we have gained valuable insights into potential risks and effective preventive measures to safeguard the security and integrity of our API implementations.

Throughout the demonstration, we used real-world examples from vulnerable applications, emphasizing the importance of robust security practices. To protect against these vulnerabilities, best practices include implementing proper authorization checks, securing authentication mechanisms, and conducting regular security assessments and testing.

As API usage continues to rise, it is paramount for developers and organizations to prioritize API security as an integral part of their overall security posture. By following the guidelines set forth in the OWASP API Top 10 and adopting proactive security measures, we can fortify our APIs against potential attacks and ensure a safer digital landscape for all users and applications.

We will be covering another series that addresses the next 5 vulnerabilities of the OWASP API Top 10.

Picture of Matthew Manalac

Matthew Manalac

Subscribe

Suggested Reading

Ready to Unlock Your Enterprise's Full Potential?