OWASP API Security (Prt 2)

6-Mass Assignment

Threat agents/Attack vectors

API Specific : Exploitability 2

Exploitation usually requires an understanding of the business logic, objects’ relations, and the API structure. Exploitation of mass assignment is easier in APIs, since by design they expose the underlying implementation of the application along with the properties’ names.

Security Weakness

Prevalence 2 : Detectability 2

Modern frameworks encourage developers to use functions that automatically bind input from the client into code variables and internal objects. Attackers can use this methodology to update or overwrite sensitive object’s properties that the developers never intended to expose.

Impacts

Technical 2 : Business Specific

Exploitation may lead to privilege escalation, data tampering, bypass of security mechanisms, and more

Is the API Vulnerable?

Objects in modern applications might contain many properties. Some of these properties should be updated directly by the client (e.g., user.first_name or user.address) and some of them should not (e.g., user.is_vip flag).

An API endpoint is vulnerable if it automatically converts client parameters into internal object properties, without considering the sensitivity and the exposure level of these properties. This could allow an attacker to update object properties that they should not have access to.

Examples for sensitive properties:

• Permission-related properties: user.is_admin, user.is_vip should only be set by admins.
• Process-dependent properties: user.cash should only be set internally after payment verification.
• Internal properties: article.created_time should only be set internally by the application.

Example Attack Scenarios

Scenario #1

A ride sharing application provides a user the option to edit basic information for their profile. During this process, an API call is sent to PUT /api/v1/users/me with the following legitimate JSON object:

{"user_name":"inons","age":24}

The request GET /api/v1/users/me includes an additional credit_balance property:

{"user_name":"inons","age":24,"credit_balance":10}

The attacker replays the first request with the following payload:

{"user_name":"attacker","age":60,"credit_balance":99999}

Since the endpoint is vulnerable to mass assignment, the attacker receives credits without paying.

Scenario #2

A video sharing portal allows users to upload content and download content in different formats. An attacker who explores the API found that the endpoint GET /api/v1/videos/{video_id}/meta_data returns a JSON object with the video’s properties. One of the properties is “mp4_conversion_params”:”-v codec h264″, which indicates that the application uses a shell command to convert the video.

The attacker also found the endpoint POST /api/v1/videos/new is vulnerable to mass assignment and allows the client to set any property of the video object. The attacker sets a malicious value as follows: “mp4_conversion_params”:”-v codec h264 && format C:/”. This value will cause a shell command injection once the attacker downloads the video as MP4.

7-Security Misconfiguration

Threat agents/Attack vectors

API Specific : Exploitability 3

Attackers will often attempt to find unpatched flaws, common endpoints, or unprotected files and directories to gain unauthorized access or knowledge of the system.

Security Weakness

Prevalence 3 : Detectability 3

Security misconfiguration can happen at any level of the API stack, from the network level to the application level. Automated tools are available to detect and exploit misconfigurations such as unnecessary services or legacy options.

Impacts

Technical 2 : Business Specific

Security misconfigurations can not only expose sensitive user data, but also system details that may lead to full server compromise

Is the API Vulnerable?

The API might be vulnerable if:

• Appropriate security hardening is missing across any part of the application stack, or if it has improperly configured permissions on cloud services.
• The latest security patches are missing, or the systems are out of date.
• Unnecessary features are enabled (e.g., HTTP verbs).
• Transport Layer Security (TLS) is missing.
• Security directives are not sent to clients (e.g., Security Headers).
• A Cross-Origin Resource Sharing (CORS) policy is missing or improperly set.

Error messages include stack traces, or other sensitive information is exposed

Example Attack Scenarios

Scenario #1

An attacker finds the .bash_history file under the root directory of the server, which contains commands used by the DevOps team to access the API:

$ curl -X GET 'https://api.server/endpoint/' -H 'authorization: Basic Zm9vOmJhcg=='

An attacker could also find new endpoints on the API that are used only by the DevOps team and are not documented.

Scenario #2

To target a specific service, an attacker uses a popular search engine to search for computers directly accessible from the Internet. The attacker found a host running a popular database management system, listening on the default port. The host was using the default configuration, which has authentication disabled by default, and the attacker gained access to millions of records with PII, personal preferences, and authentication data.

Scenario #3

Inspecting traffic of a mobile application an attacker finds out that not all HTTP traffic is performed on a secure protocol (e.g., TLS). The attacker finds this to be true, specifically for the download of profile images. As user interaction is binary, despite the fact that API traffic is performed on a secure protocol, the attacker finds a pattern on API responses size, which he uses to track user preferences over the rendered content (e.g., profile images).

8-Injection

Threat agents/Attack vectors

API Specific : Exploitability 3

Attackers will feed the API with malicious data through whatever injection vectors are available (e.g., direct input, parameters, integrated services, etc.), expecting it to be sent to an interpreter.

Security Weakness

Prevalence 2 : Detectability 3

Injection flaws are very common and are often found in SQL, LDAP, or NoSQL queries, OS commands, XML parsers, and ORM. These flaws are easy to discover when reviewing the source code. Attackers can use scanners and fuzzers

Impacts

Technical 3 : Business Specific

Injection can lead to information disclosure and data loss. It may also lead to DoS, or complete host takeover

Is the API Vulnerable?

The API is vulnerable to injection flaws if:

• Client-supplied data is not validated, filtered, or sanitized by the API.
• Client-supplied data is directly used or concatenated to SQL/NoSQL/LDAP queries, OS commands, XML parsers, and Object Relational Mapping (ORM)/Object Document Mapper (ODM).
• Data coming from external systems (e.g., integrated systems) is not validated, filtered, or sanitized by the API.

Example Attack Scenarios

Scenario #1

Firmware of a parental control device provides the endpoint /api/CONFIG/restore which expects an appId to be sent as a multipart parameter. Using a decompiler, an attacker finds out that the appId is passed directly into a system call without any sanitization:

snprintf(cmd, 128, "%srestore_backup.sh /tmp/postfile.bin %s %d",

         "/mnt/shares/usr/bin/scripts/", appid, 66);

system(cmd);

The following command allows the attacker to shut down any device with the same vulnerable firmware:

$ curl -k "https://${deviceIP}:4567/api/CONFIG/restore" -F 'appid=$(/etc/pod/power_down.sh)'

Scenario #2

We have an application with basic CRUD functionality for operations with bookings. An attacker managed to identify that NoSQL injection might be possible through bookingId query string parameter in the delete booking request. This is how the request looks like: DELETE /api/bookings?bookingId=678.

The API server uses the following function to handle delete requests:

router.delete('/bookings', async function (req, res, next) {

  try {

      const deletedBooking = await Bookings.findOneAndRemove({'_id' : req.query.bookingId});

      res.status(200);

  } catch (err) {

     res.status(400).json({error: 'Unexpected error occured while processing a request'});

  }

});

The attacker intercepted the request and changed bookingId query string parameter as shown below. In this case, the attacker managed to delete another user’s booking:

DELETE /api/bookings?bookingId[$ne]=678

9-Improper Assets Management

Threat agents/Attack vectors

API Specific : Exploitability 3

Old API versions are usually unpatched and are an easy way to compromise systems without having to fight state-of-the-art security mechanisms, which might be in place to protect the most recent API versions.

Security Weakness

Prevalence 3 : Detectability 2

Outdated documentation makes it more difficult to find and/or fix vulnerabilities. Lack of assets inventory and retire strategies leads to running unpatched systems, resulting in leakage of sensitive data. It’s common to find unnecessarily exposed API hosts because of modern concepts like microservices, which make applications easy to deploy and independent (e.g., cloud computing, k8s).

Impacts

Technical 2 : Business Specific

Attackers may gain access to sensitive data, or even takeover the server through old, unpatched API versions connected to the same database

Is the API Vulnerable?

The API might be vulnerable if:

• The purpose of an API host is unclear, and there are no explicit answers to the following questions:
  • Which environment is the API running in (e.g., production, staging, test, development)?
  • Who should have network access to the API (e.g., public, internal, partners)?
  • Which API version is running?
  • What data is gathered and processed by the API (e.g., PII)?
  • What’s the data flow?
• There is no documentation, or the existing documentation is not updated.
• There is no retirement plan for each API version.
• Hosts inventory is missing or outdated.
• Integrated services inventory, either first- or third-party, is missing or outdated.

Old or previous API versions are running unpatched

Example Attack Scenarios

Scenario #1

After redesigning their applications, a local search service left an old API version (api.someservice.com/v1) running, unprotected, and with access to the user database. While targeting one of the latest released applications, an attacker found the API address (api.someservice.com/v2). Replacing v2 with v1 in the URL gave the attacker access to the old, unprotected API, exposing the personal identifiable information (PII) of over 100 Million users.

Scenario #2

A social network implemented a rate-limiting mechanism that blocks attackers from using brute-force to guess reset password tokens. This mechanism wasn’t implemented as part of the API code itself, but in a separate component between the client and the official API (www.socialnetwork.com). A researcher found a beta API host (www.mbasic.beta.socialnetwork.com) that runs the same API, including the reset password mechanism, but the rate limiting mechanism was not in place. The researcher was able to reset the password of any user by using a simple brute-force to guess the 6 digits token.

10-Insufficient Logging & Monitoring

Threat agents/Attack vectors

API Specific : Exploitability 2

Attackers take advantage of lack of logging and monitoring to abuse systems without being noticed.

Security Weakness

Prevalence 3 : Detectability 1

Without logging and monitoring, or with insufficient logging and monitoring, it is almost impossible to track suspicious activities and respond to them in a timely fashion.

Impacts

Technical 2 : Business Specific

Without visibility over on-going malicious activities, attackers have plenty of time to fully compromise systems

Is the API Vulnerable?

The API is vulnerable if:

• It does not produce any logs, the logging level is not set correctly, or log messages do not include enough detail.
• Log integrity is not guaranteed (e.g., Log Injection).
• Logs are not continuously monitored.
• API infrastructure is not continuously monitored.

Example Attack Scenarios

Scenario #1

Access keys of an administrative API were leaked on a public repository. The repository owner was notified by email about the potential leak, but took more than 48 hours to act upon the incident, and access keys exposure may have allowed access to sensitive data. Due to insufficient logging, the company is not able to assess what data was accessed by malicious actors.

Scenario #2

A video-sharing platform was hit by a “large-scale” credential stuffing attack. Despite failed logins being logged, no alerts were triggered during the timespan of the attack. As a reaction to user complaints, API logs were analyzed and the attack was detected. The company had to make a public announcement asking users to reset their passwords, and report the incident to regulatory authorities