OWASP API Top 10 — Part 2

6 min readOct 13, 2020

Due to the widespread usage of APIs, and the fact that attackers realize APIs are a new attack frontier, the OWASP API Security Top 10 Project was launched. This project was designed to help organizations, developers, and application security teams become aware of the risks associated with APIs. The OWASP API Security Top 10 project focuses on the top ten vulnerabilities related to API security.

In our previous article, we provided a high-level view of the top five vulnerabilities related to APIs. These included vulnerabilities ranging from Broken Object Level Authorization, Broken User Authentication up to Broken Function Level Authorization.We also discussed the various possible ways to mitigate those issues.

Now we have come up with the second part of the article wherein we focus on the remaining five vulnerabilities. We have tried to clarify the last five risks to help organizations understand the dangers associated with deficient API implementations.

API 6: 2019 — Mass Assignment

Often it is seen that applications need users to update information such as their contact information, personal data,etc,. But this might lead to Mass Assignment if the user-provided details are directly bound to the data models without proper filtering.

Moreover, it could pose a grave risk if the user can update details that should only be set by an administrator or the application itself.

For Example:

· Consider a ride-sharing application that 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”:”inons”,”age”:60,”credit_balance”:99999}

· Thus the attacker receives credits without paying.

How to prevent it:

Automatic mapping of client inputs to internal variables should be avoided
Explicitly define all the parameters you are expecting

· Ensure that only the people with correct privileges can access the information that is being retrieved

API 7: 2019 — Security Misconfiguration

Attackers tend to find unpatched flaws/unprotected files/directories and search for an exploitable attack vector to gain unauthorized access/gain critical information about the system.

For Example:

Consider a situation where the attacker finds the .bash_history file which contains the commands employed by the DevOps team to access the API.

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

Unnecessary HTTP verbs are enabled (e.g. PUT, DELETE, etc.) for accessing the API.
There are error messages with stack traces while requesting/sending data via the API.
Missing CORS policy or security headers.

How to prevent it:

Use Whitelisting on API actions and make sure that the API can be accessed by the specified HTTP verbs, all other HTTP verbs should be disabled (e.g. HEAD).

For example, a GET request to read data, PUT to update data, POST to create data, and DELETE to delete data.

The PUT, POST, and DELETE methods need to be protected from Cross-Site Request Forgery (CSRF).
APIs which are accessed from browser-based clients should implement a proper Cross-Origin Resource Sharing (CORS) Policy.

API 8: 2019 — Injections

An attacker inputs malicious data through various injection vectors available like parameters in the URL or directly in input fields. The attacker attempts SQL Injections, NoSQL Injections, Command Injections, etc. Many of the times data coming from the user and external systems (e.g., integrated systems) is not validated, filtered, or sanitized by the API. And this proves to be a breeding ground for such attacks.

Injection flaws are very common and are often found in SQL, LDAP, or NoSQL queries, OS commands, XML parsers, and ORM. The injection attacksoften lead to information disclosure and data loss. It may also lead to DoS or a complete host takeover.

For Example:

Consider a scenario where we have an application with basic CRUD functionality

(Create, read, update and delete) for operations with bookings, and that a NoSQL injection is possible with the bookingId parameter with the DELETE operation.

Original Request :DELETE /api/bookings?bookingId=678

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

In this case, the attacker managed to delete another user’s booking with help of a NoSQL Injection.

How to prevent it:

Proper Input Sanitization, implement whitelisting instead of blacklisting.
Special characters should be escaped using the specific syntax for the target interpreter.
Validate, Filter, and sanitize all incoming data. Always limit the number of returned records to prevent mass disclosure incase of injection.

API 9: 2019 — Improper Assets Management

Outdated/poor API documentation and improper configuration can lead to uncertainty like which environment is the API running in (e.g., production, staging, test, development)?, Which API version is running? Etc,.lack ofa retirement plan for each API version. In addition to all this the Integrated services inventory, either first- or third-party, might be missing or outdated.

Attackers find various versions of the API (for example staging, testing, beta, or earlier versions) that are not well protected as the production API, and use those to launch attacks.

Since APIs tend to expose more endpoints than traditional web applications, making updated documentation about deployed API versions inventory plays an important role to tackle issues such as deprecated API versions and exposed debug endpoints.

For example:

Consider an instance where an organization after redesigning its applications, left an old API version (api.someservice.com/v1) running, unprotected, and with access to the user database.
If the attacker has access to the API address (api.someservice.com/v2) he can replace v2 with v1 in the URL, which would give the attacker access to the old, unprotected API. Thus exposing the personally identifiable information (PII) of over 100 Million users.

How to prevent it:

Inventory all the API hosts and document about the API environment (e.g., production, staging, test, development), who should have access to the host (e.g., public, internal, partners) and the API version.
Document all aspects of your API such as authentication, errors, redirects, rate limiting, cross-origin resource sharing (CORS) policy, and endpoints, including their parameters, requests, and responses.
Use API security firewalls for all exposed versions of API
Avoid using production data with non-production API deployments.
Limit access to anything that should not be public
Properly retire old versions of APIs

API 10: 2019 — Insufficient Logging & Monitoring

To track suspicious activities there should be sufficient logging and monitoring done. In case of a lack of proper monitoring, attackers get a lot of time to completely compromise the system.

One of the most important aspects here is securing the log files. Not everyone should be able to access and modify the log files. The integrity of the log files should be maintained.

For example:

Consider a scenario where a video-sharing platform was hit by credential stuffing attack. Despite failed login attempts being logged, no alerts were triggered during 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.

How to prevent it:

Protect logs with highly sensitive information
Log failed attempts, denied access, or any failures in security policy checks
Avoid having sensitive data in logs
Write logs in a format that could be consumed by a log management solution such as Splunk.

The ever-increasing API usage has undoubtedly made life easier for a lot of developers but it also has opened a fresh set of challenges to the organizations that already remain grappled with the cyber attacks. And most importantly the entire game changes when you move from developing a traditional application to an API-based application.

We hope both our articles (Part 1 & Part 2) helped in demonstrating the importance of securing the APIs and become handy for anyone who wants a quick glimpse at the OWASP API Security Top 10.

References:

Anu Bhakhtadas

Siddhant Chouhan

Cyber Security Researchers @ Andy InfoSec

OWASP API Top 10 — Part 2

Written by Andy InfoSec