OWASP API TOP 10 2023

1. API1:2023: Broken Object Level Authorization

2. API2:2023 - Broken Authentication

3. API3:2023 - Broken Object Property Level Authorization

4. API4:2023 - Unrestricted Resource Consumption

5. API5:2023 - Broken Function Level Authorization

6. API6:2023 - Unrestricted Access to Sensitive Business Flow

7. API7:2023 - Server Side Request Forgery

8. API8:2023 - Security Misconfiguration

9. API9:2023: Improper Assets Management

10. API10:2023 - Unsafe Consumption of APIs

API1:2023: Broken Object Level Authorization

Broken Object Level Authorization occurs when an API exposes endpoints that handle object identifiers, creating a wide attack surface Level Access Control issue. Attackers can exploit these endpoints by manipulating the ID values sent in requests, allowing them to bypass authorization and perform unauthorized actions on these objects.

• API Endpoint for Updating User Profile: HTTP Request

• The API Endpoint is used to update user details based on the userId provided in the json body. But if the authorization checks are not enforced properly, an attacker can change the userId to any valid userId and update their personal information

PUT /api/user/profile
Authorization: Bearer <token>
Content-Type: application/json
{
  "userId": "456",   // Attacker manipulates the userId
  "username": "malicious_user",
  "email": "malicious.user@example.com",
  "role": "admin"
}

HTTP Response (Success):

PUT /api/user/profile
Authorization: Bearer <token>
Content-Type: application/json
{
  "userId": "456",   // Attacker manipulates the userId
  "username": "malicious_user",
  "email": "malicious.user@example.com",
  "role": "admin"
}

Similar to the previous request, the Authorization header contains the user's authentication token.

This is the vulnerable code for this

PUT /api/user/profile
Authorization: Bearer <token>
Content-Type: application/json
{
  "userId": "456",   // Attacker manipulates the userId
  "username": "malicious_user",
  "email": "malicious.user@example.com",
  "role": "admin"
}

In this example, the vulnerability lies in the insufficient authorization check in the /api/user/profile PUT endpoint. The server checks if the user making the request (req.body.userId) matches the authenticated user (userId) extracted from the token). However, it lacks additional checks, such as ensuring the user has the appropriate role or ownership of the resource being updated.

Another type of BOLA, known as "BOLA by parameter pollution", occurs when an attacker manipulates or injects multiple instances of the same parameter in a request. This allows them to bypass authorization checks and gain unauthorized access to resources and objects.

Visit this blog to understand how attackers manually exploit this vulnerability with prevention and how you can automate testing for this vulnerability using Akto.

How To Test BOLA by Parameter Pollution Using Akto

API2:2023 - Broken Authentication

Broken Authentication in API endpoints happens when the API fails to properly enforce authentication checks, allowing unauthorized users to gain access to sensitive data or perform privileged actions. This could involve issues such as the API not validating authentication tokens properly, or session management being improperly implemented. As a result, an attacker could impersonate other users or even gain administrative access, leading to potential data breaches and unauthorized transactions.

Some Types of Broken Authentication:

JWT None Algorithm

JWT (JSON Web Token) is a compact, URL-safe means of representing claims to be transferred between two parties. The "none" algorithm in JWT is a controversial part of the JWT specification that signifies that the integrity of the token has not been digitally signed or MACed.

In essence, the "none" algorithm means that the security of the JWT relies entirely on the transport layer, without any cryptographic protection. When a JWT with the "none" algorithm is received, it should be accepted without having to validate any signature. This could potentially lead to security vulnerabilities if the token is intercepted and tampered with during transit.

You can automate broken authentication testing from Akto's test editor.

Broken User Authentication (BUA)

CSRF By Removing CSRF Token

Cross-Site Request Forgery (CSRF) is a type of online attack that tricks the victim into submitting a malicious request. It uses the identity and privileges of the victim to perform an undesired function on their behalf.

The CSRF token is a defense mechanism used to protect against CSRF attacks. It is a unique, random value associated with a user's session and is typically included as a parameter in requests that cause a state change on the server (like changing a password). When the server receives a state-changing request, it checks the CSRF token in the request against the CSRF token associated with the session. If they match, the request is considered legitimate.

If a CSRF token is removed, the application becomes vulnerable to CSRF attacks. Without the token, the application won't be able to verify whether the state-changing request was intentionally made by the user or was initiated by a third party (the attacker). This could lead to unauthorized actions being performed on the user's behalf without their knowledge or consent.

To mitigate this vulnerability, it's essential to include CSRF tokens in all state-changing requests, and to verify the token on the server for each of these requests. Also, the application should not have any "open" endpoints that change the application state and do not require a CSRF token. If an endpoint doesn't need to protect against CSRF, it's likely that it doesn't need to cause a state change.

CSRF test by replacing with invalid csrf token - Akto

You can explore more scenarios here.

Prevention

• Secure Passwords:

  • Enforce strong password policies for users, including the use of complex passwords and regular password updates.

• Multi-Factor Authentication (MFA):

  • Implement multi-factor authentication to add an extra layer of security beyond just passwords.

• Secure Session Management:

  • Use secure session management practices, including random session IDs, session timeouts, and session rotation.

• Token-Based Authentication:

  • If applicable, consider using token-based authentication mechanisms like JWT (JSON Web Tokens) and ensure secure token storage and transmission.

API3:2023 - Broken Object Property Level Authorization

Broken Object Property Level Authorization is similar to Broken Object Level Authorization, but it occurs when an API allows unauthorized access to certain properties of an object. This can happen when an API endpoint exposes object properties without proper authorization checks, allowing attackers to manipulate these properties and perform unauthorized actions. For instance, if the API does not enforce proper authorization checks, an attacker could potentially modify properties of any object, leading to data manipulation or unauthorized actions.

Two categories are:

1. Excessive Data Exposure

   Sensitive information that could be unnecessarily exposed by an API endpoint can include a broad range of data, depending on the context and the nature of the application. Examples of such sensitive information may include:

• User credentials such as usernames, passwords, or authentication tokens.

• Personal identifiable information (PII) such as full names, addresses, phone numbers, or social security numbers.

• Confidential business data such as sales figures, strategic plans, internal communications, or proprietary technology details.

• Financial data such as credit card numbers, bank account details, or transaction histories.

• Health records or other sensitive personal data.

2. Mass Assignment
   Mass Assignment is a vulnerability that occurs when an application populates the properties of an object directly from user input, without proper validation or filtering. This allows an attacker to set values they shouldn't have access to, leading to potential data manipulation or unauthorized actions.
   Check out how attackers exploit the mass assignment vulnerability with prevention and learn how to utilize Akto to automate the detection of this vulnerability.

API4:2023 - Unrestricted Resource Consumption

Unrestricted Resource Consumption, often referred to as a Denial of Service (DoS) attack, occurs when an API allows an attacker to consume resources (such as memory, CPU, or disk space) without limit, causing the system to slow down or crash. This can happen when the API doesn't implement proper rate limiting or doesn't handle large amounts of data properly, allowing an attacker to send large amounts of requests or data to overwhelm the system.

Consider an API endpoint that is responsible for file uploads. If there are no proper checks on the size or type of the file that a user can upload, an attacker can exploit this by uploading very large files or many files at once, consuming the server's resources.

Here's an example of how this could occur:

// Endpoint for uploading files
app.post('/api/file/upload', (req, res) => {
  // The uploaded file is stored in the 'file' property of req.files
  const file = req.files.file;
  // Save the file to the server
  file.mv(`/server/path/to/files/${file.name}`);
  res.json({ message: 'File uploaded successfully.' });
});

In this example, there are no checks on the size or type of the file being uploaded. An attacker could upload a very large file, or many files at once, potentially causing the server to run out of disk space or memory and slowing down or crashing the system.

Prevention

• Rate Limiting:

  • Implement rate limiting to restrict the number of requests a user or IP address can make within a specific time frame. This prevents excessive resource consumption by limiting the frequency of API calls.

• Validate Request:

  • Ensure the server verifies the data it receives from the body parameters returning records.

API5:2023 - Broken Function Level Authorization

Broken Function Level Authorization is a security vulnerability that occurs when an API endpoint allows unauthorized users to access functionality they should not be able to. This can happen when an API fails to properly check a user's role or permissions before allowing them to execute a function or access a resource. As a result, an unauthorized user could execute functions or access resources that they should not be able to, potentially leading to unauthorized actions or data breaches.
Read this blog to gain a deeper understanding of this vulnerability as well as prevention, and learn how to automate the detection of this vulnerability using Akto.

How to test Broken Function Level Authorization by Changing the HTTP Method Using Akto?

API6:2023 - Unrestricted Access to Sensitive Business Flow

API6:2023 - Unrestricted Access to Sensitive Business Flow refers to a security risk where an API does not enforce adequate restrictions on access to sensitive business processes. This can allow unauthorized users or systems to interact with these processes, potentially leading to unauthorized actions or data breaches. These sensitive processes could include things like user registration, data processing, or transaction handling. Without proper access controls in place, an attacker could manipulate these processes for malicious purposes.
Some examples of sensitive business flows and potential risks associated with unrestricted access:

• Medical Records Access:

  • Vulnerability: Unrestricted access to medical records retrieval API.

  • Risk: An attacker could retrieve sensitive medical information of individuals, violating privacy laws and potentially using the information for identity theft or malicious purposes.

• Appointment Scheduling:

  • Vulnerability: An attacker manipulates the appointment scheduling system to block all available slots.

  • Risk: This could disrupt normal business operations or services, causing inconvenience to genuine users and potentially impacting revenue.

• Employee Salary Modification:

  • Vulnerability: Lack of proper authorization checks on an API endpoint that allows modification of employee salaries.

  • Risk: An attacker could modify the salary of any employee, leading to financial losses, demoralization among employees, and potential legal issues.

• Document Upload and Sharing:

  • Vulnerability: Unrestricted access to document upload and sharing functionality.

  • Risk: An attacker could upload malicious files, inappropriate content, or confidential documents, impacting the reputation of the platform and potentially causing legal issues.

• Inventory Exhaustion:

  • The attacker aims to deplete the entire stock of a particular high-demand item during a short time frame.

  • This rapid depletion prevents genuine customers from securing the product, creating a sense of urgency and scarcity.

Prevention

• Block Tor Exit Nodes and Proxies:

  • To enhance security, consider using a Web Application Firewall (WAF) and implementing request rewrite rules. These measures can help detect and mitigate attacks, while still allowing legitimate traffic to pass through.

  • Risk: An attacker could upload malicious files, inappropriate content, or confidential documents, impacting the reputation of the platform and potentially causing legal issues.

• Secure Access to APIs:

  • The attacker aims to deplete the entire stock of a particular high-demand item during a short time frame. This rapid depletion prevents genuine customers from securing the product, creating a sense of urgency and scarcity.

  • Recognize and pinpoint critical business flows that could pose a threat to the API if used excessively.

API7:2023 - Server Side Request Forgery

Server Side Request Forgery (SSRF) is a type of web security vulnerability that allows an attacker to induce the server-side application to make HTTP requests to an arbitrary domain of the attacker's choosing. In a typical SSRF attack, the attacker tricks the server into making a connection back to itself, or to another server that the attacker controls, or to an internal resource that the server can access but is not normally accessible to the attacker.

Certainly, here's a revised example considering the endpoint as an API endpoint:

Suppose we have a web application that includes an API endpoint designed to fetch an image from a user-provided URL:

Here's what the Python code for that API endpoint might look like:

from flask import Flask, request
import requests
app = Flask(__name__)
@app.route('/api/fetch_image', methods=['GET'])
def fetch_image():
    image_url = request.args.get('url')
    image = requests.get(image_url).content
    return f'Successfully fetched {image_url}'
if __name__ == '__main__':
    app.run()

In this example, the server fetches the image from the URL provided in the 'url' query parameter and returns a success message.

An attacker could exploit this by providing a URL that points to an internal resource. For example, they could provide the URL http://localhost:5000/admin as the 'url' query parameter:

GET /api/fetch_image?url=http://localhost:5000/admin HTTP/1.1
Host: vulnerable-website.com

The server would then fetch the contents from http://localhost:5000/admin and return a success message:

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Successfully fetched <http://localhost:5000/admin>

In this case, the server could reveal sensitive information from the /admin path on localhost that the attacker should not have access to. This is an example of a Server Side Request Forgery (SSRF) attack.

Prevention

• Input validation: Validate and sanitize user inputs to prevent malicious data from being used in requests.

• Whitelist URLs: Whitelist the domains that your application uses.

• Enable Authentication: Make sure that the authentication is enables in every service that is running in your internal system to reduce damage.

• Use Regex: If you can't whitelist domains, you can use regex for information with a simple structure, such as a password or a zip code, to check its safety. However, for more complex data, it's advisable to use specialized tools designed for the task. This avoids the creation of intricate rules that may be difficult to manage and potentially erroneous.

• Monitor outgoing requests: Monitor and log outgoing network requests to detect unusual or unexpected patterns that may indicate an SSRF attack.