OWASP API Security (Prt1)

What is API Security?

A foundational element of innovation in today’s app-driven world is the API. From banks, retail and transportation to IoT, autonomous vehicles and smart cities, APIs are a critical part of modern mobile, SaaS and web applications and can be found in customer-facing, partner-facing and internal applications. By nature, APIs expose application logic and sensitive data such as Personally Identifiable Information (PII) and because of this have increasingly become a target for attackers. Without secure APIs, rapid innovation would be impossible.

API Security focuses on strategies and solutions to understand and mitigate the unique vulnerabilities and security risks of Application Programming Interfaces (APIs).

1-Broken Object Level Authorization

Threat agents/Attack vectors

API Specific : Exploitability 3

Attackers can exploit API endpoints that are vulnerable to broken object level authorization by manipulating the ID of an object that is sent within the request. This may lead to unauthorized access to sensitive data. This issue is extremely common in API-based applications because the server component usually does not fully track the client’s state, and instead, relies more on parameters like object IDs, that are sent from the client to decide which objects to access.

Security Weakness

Prevalence 3 : Detectability 2

This has been the most common and impactful attack on APIs. Authorization and access control mechanisms in modern applications are complex and wide-spread. Even if the application implements a proper infrastructure for authorization checks, developers might forget to use these checks before accessing a sensitive object. Access control detection is not typically amenable to automated static or dynamic testing.

Impacts

Technical 3 : Business Specific

Unauthorized access can result in data disclosure to unauthorized parties, data loss, or data manipulation. Unauthorized access to objects can also lead to full account takeover

Is the API Vulnerable?

Object level authorization is an access control mechanism that is usually implemented at the code level to validate that one user can only access objects that they should have access to.

Every API endpoint that receives an ID of an object, and performs any type of action on the object, should implement object level authorization checks. The checks should validate that the logged-in user does have access to perform the requested action on the requested object. Failures in this mechanism typically leads to unauthorized information disclosure, modification, or destruction of all data

Example Attack Scenarios

Scenario #1

An e-commerce platform for online stores (shops) provides a listing page with the revenue charts for their hosted shops. Inspecting the browser requests, an attacker can identify the API endpoints used as a data source for those charts and their pattern /shops/{shopName}/revenue_data.json. Using another API endpoint, the attacker can get the list of all hosted shop names. With a simple script to manipulate the names in the list, replacing {shopName} in the URL, the attacker gains access to the sales data of thousands of e-commerce stores.

Scenario #2

While monitoring the network traffic of a wearable device, the following HTTP PATCH request gets the attention of an attacker due to the presence of a custom HTTP request header X-User-Id: 54796. Replacing the X-User-Id value with 54795, the attacker receives a successful HTTP response, and is able to modify other users’ account data.

2-Broken User Authentication

Threat agents/Attack vectors

API Specific : Exploitability 3

Authentication in APIs is a complex and confusing mechanism. Software and security engineers might have misconceptions about what are the boundaries of authentication and how to implement it correctly. In addition, the authentication mechanism is an easy target for attackers, since it’s exposed to everyone. These two points makes the authentication component potentially vulnerable to many exploits

Security Weakness

Prevalence 2 : Detectability 2

There are two sub-issues: 1. Lack of protection mechanisms: APIs endpoints that are responsible for authentication must be treated differently from regular endpoints and implement extra layers of protection 2. Misimplementation of the mechanism: The mechanism is used / implemented without considering the attack vectors, or it’s the wrong use case (e.g., an authentication mechanism designed for IoT clients might not be the right choice for web applications).

Impacts

Technical 3 : Business Specific

Attackers can gain control to other users’ accounts in the system, read their personal data, and perform sensitive actions on their behalf, like money transactions and sending personal messages.

Is the API Vulnerable?

Authentication endpoints and flows are assets that need to be protected. “Forgot password / reset password” should be treated the same way as authentication mechanisms.

An API is vulnerable if it:

• Permits credential stuffing whereby the attacker has a list of valid usernames and passwords.
• Permits attackers to perform a brute force attack on the same user account, without presenting captcha/account lockout mechanism.
• Permits weak passwords.
• Sends sensitive authentication details, such as auth tokens and passwords in the URL.
• Doesn’t validate the authenticity of tokens.
• Accepts unsigned/weakly signed JWT tokens ("alg":"none")/doesn’t validate their expiration date.
• Uses plain text, non-encrypted, or weakly hashed passwords.
• Uses weak encryption keys.

Example Attack Scenarios

Scenario #1

Credential stuffing (using lists of known usernames/passwords), is a common attack. If an application does not implement automated threat or credential stuffing protections, the application can be used as a password oracle (tester) to determine if the credentials are valid.

Scenario #2

An attacker starts the password recovery workflow by issuing a POST request to /api/system/verification-codes and by providing the username in the request body. Next an SMS token with 6 digits is sent to the victim’s phone. Because the API does not implement a rate limiting policy, the attacker can test all possible combinations using a multi-threaded script, against the /api/system/verification-codes/{smsToken} endpoint to discover the right token within a few minutes.

3-Excessive Data Exposure

Threat agents/Attack vectors

API Specific : Exploitability 3

Exploitation of Excessive Data Exposure is simple, and is usually performed by sniffing the traffic to analyse the API responses, looking for sensitive data exposure that should not be returned to the user.

Security Weakness

Prevalence 2 : Detectability 2

APIs rely on clients to perform the data filtering. Since APIs are used as data sources, sometimes developers try to implement them in a generic way without thinking about the sensitivity of the exposed data. Automatic tools usually can’t detect this type of vulnerability because it’s hard to differentiate between legitimate data returned from the API, and sensitive data that should not be returned without a deep understanding of the application

Impacts

Technical 2 : Business Specific

Excessive Data Exposure commonly leads to exposure of sensitive data

Is the API Vulnerable?

The API returns sensitive data to the client by design. This data is usually filtered on the client side before being presented to the user. An attacker can easily sniff the traffic and see the sensitive data.

Example Attack Scenarios

Scenario #1

The mobile team uses the /api/articles/{articleId}/comments/{commentId} endpoint in the articles view to render comments metadata. Sniffing the mobile application traffic, an attacker finds out that other sensitive data related to comment’s author is also returned. The endpoint implementation uses a generic toJSON() method on the User model, which contains PII, to serialize the object.

Scenario #2

An IOT-based surveillance system allows administrators to create users with different permissions. An admin created a user account for a new security guard that should only have access to specific buildings on the site. Once the security guard uses his mobile app, an API call is triggered to: /api/sites/111/cameras in order to receive data about the available cameras and show them on the dashboard. The response contains a list with details about cameras in the following format: {"id":"xxx","live_access_token":"xxxx-bbbbb","building_id":"yyy"}. While the client GUI shows only cameras which the security guard should have access to, the actual API response contains a full list of all the cameras in the site.

4-Lack of Resources & Rate Limiting

Threat agents/Attack vectors

API Specific : Exploitability 2

Exploitation requires simple API requests. No authentication is required. Multiple concurrent requests can be performed from a single local computer or by using cloud computing resources.

Security Weakness

Prevalence 3 : Detectability 3

It’s common to find APIs that do not implement rate limiting or APIs where limits are not properly set

Impacts

Technical 2 : Business Specific

Exploitation may lead to DoS, making the API unresponsive or even unavailable

Is the API Vulnerable?

API requests consume resources such as network, CPU, memory, and storage. The amount of resources required to satisfy a request greatly depends on the user input and endpoint business logic. Also, consider the fact that requests from multiple API clients compete for resources. An API is vulnerable if at least one of the following limits is missing or set inappropriately (e.g., too low/high):

• Execution timeouts
• Max allocable memory
• Number of file descriptors
• Number of processes
• Request payload size (e.g., uploads)
• Number of requests per client/resource
• Number of records per page to return in a single request response

Example Attack Scenarios

Scenario #1

An attacker uploads a large image by issuing a POST request to /api/v1/images. When the upload is complete, the API creates multiple thumbnails with different sizes. Due to the size of the uploaded image, available memory is exhausted during the creation of thumbnails and the API becomes unresponsive.

Scenario #2

We have an application that contains the users’ list on a UI with a limit of 200 users per page. The users’ list is retrieved from the server using the following query: /api/users?page=1&size=200. An attacker changes the size parameter to 200 000, causing performance issues on the database. Meanwhile, the API becomes unresponsive and is unable to handle further requests from this or any other clients (aka DoS). The same scenario might be used to provoke Integer Overflow or Buffer Overflow errors.

5-Broken Function Level Authorization

Threat agents/Attack vectors

API Specific : Exploitability 3

Exploitation requires the attacker to send legitimate API calls to the API endpoint that they should not have access to. These endpoints might be exposed to anonymous users or regular, non-privileged users. It’s easier to discover these flaws in APIs since APIs are more structured, and the way to access certain functions is more predictable (e.g., replacing the HTTP method from GET to PUT, or changing the “users” string in the URL to “admins”).

Security Weakness

Prevalence 2 : Detectability 1

Authorization checks for a function or resource are usually managed via configuration, and sometimes at the code level. Implementing proper checks can be a confusing task, since modern applications can contain many types of roles or groups and complex user hierarchy (e.g., sub-users, users with more than one role).

Impacts

Technical 2 : Business Specific

Such flaws allow attackers to access unauthorized functionality. Administrative functions are key targets for this type of attack

Is the API Vulnerable?

The best way to find broken function level authorization issues is to perform deep analysis of the authorization mechanism, while keeping in mind the user hierarchy, different roles or groups in the application, and asking the following questions:

• Can a regular user access administrative endpoints?
• Can a user perform sensitive actions (e.g., creation, modification, or erasure) that they should not have access to by simply changing the HTTP method (e.g., from GET to DELETE)?
• Can a user from group X access a function that should be exposed only to users from group Y, by simply guessing the endpoint URL and parameters (e.g., /api/v1/users/export_all)?

Don’t assume that an API endpoint is regular or administrative only based on the URL path.

While developers might choose to expose most of the administrative endpoints under a specific relative path, like api/admins, it’s very common to find these administrative endpoints under other relative paths together with regular endpoints, like api/users.

Example Attack Scenarios

Scenario #1

During the registration process to an application that allows only invited users to join, the mobile application triggers an API call to GET /api/invites/{invite_guid}. The response contains a JSON with details about the invite, including the user’s role and the user’s email.

An attacker duplicated the request and manipulated the HTTP method and endpoint to POST /api/invites/new. This endpoint should only be accessed by administrators using the admin console, which does not implement function level authorization checks.

The attacker exploits the issue and sends himself an invite to create an admin account:

POST /api/invites/new

{“email”:”hugo@malicious.com”,”role”:”admin”}

Scenario #2

An API contains an endpoint that should be exposed only to administrators – GET /api/admin/v1/users/all. This endpoint returns the details of all the users of the application and does not implement function-level authorization checks. An attacker who learned the API structure takes an educated guess and manages to access this endpoint, which exposes sensitive details of the users of the application.