APIs become more and more prevalent as the foundation of modern applications. While in layered applications APIs mostly were used between the browser and the backend application layer, todayâs APIs have a much broader set of use cases that go far beyond client/server APIs. There are APIs that support mobile back-ends, APIs for IOTs, APIs that connect segments of distributed systems, internal APIs between microservices in Kubernetes architectures, device-to-device APIs, APIs that are used to deliver external services, such as map or weather APIs and more. In addition to the same risks that web applications are exposed to, APIs are faced with a number of unique security risks and vulnerabilities.
As appsec professionals, weâve been long relying on OWASP project and, specifically, OWASP Top 10 risks document. Now, there is a new body of work under OWASP framework, which is addressing API specific issues. In this document, we will provide an overview of this work.
The original document is published on github. We thank the project team for providing excellent examples of the exploits for every one of the top 10 risks, which we will quote in this document for clarity.
API1:2019 – Broken Object Level Authorization
Object-level authorization is all about controlling access based on the scope of permissible user data and object access. A simple physical world example is a hotel room key which is coded to only open the room you paid for, as opposed to a master key used by a maid that opens all the rooms on the floor. If the application does not implement object-based controls at the code level, itâs an equivalent of any hotel guest been able to go into any of the rooms and steal valuables.
Lack of or improper implementation of object-level authorization for every API endpoint may result in information disclosure or unauthorized data modifications.
If a data source is based on the input from the user, API object-level authorization is ever more important. The mechanisms might get quite complicated, especially if object hierarchies are based on graphs and there is no clear separation of administrative functions.
Example
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.
What To Do
⢠Implement an authorization mechanism checks client object/data record access policies and makes sure the logged in user is authorized to perform the requested action on the request object
⢠Make object IDs hard to guess
⢠Conduct periodic tests of the authorization.
API2:2019 – Broken User Authentication
Authentication in itâs simplest form is reliably figuring out who the logged in user is. Unfortunately, it is not always easy with passwords that can be compromised or some logic where authentication is missing for certain flows. Incorrect implementation can also result in privilege escalation or in unprivileged users assuming an administrative identity.
Typical implementation mistakes include:
- Weak authentication artifacts, such as weak passwords, unsigned tokens or weak encryption keys
- Lack of protection mechanisms that allow for bruteforce password attacks or credential stuffing
- Unprotected flows such as âforgot passwordâ or privilege escalation
Example
Credential stuffing (using lists of known usernames/passwords), is a common attack. If an application does not implement automated threat or credential stuffing protection, the application can be used as a password oracle (tester) to determine if the credentials are valid.
What To Do
- Know what authentication mechanisms are used throughout your system and what are their potential flows
- Implement protection mechanisms and compensating controls for brute-force attacks, dictionary attacks, and credential stuffing
- Beware of unprotected/lesser protected password recovery and credentials reset processes
- Use multi-factor authentication and password-less authentication if at all possible
API3:2019 – Excessive Data Exposure
This risk is somewhat similar to the risk of improper object authorization. With this code flaw, the implementer is looking to simplify their life by delegating data filtering to the client.
If we were to look at this risk in the physical world, it would be like handing somebody a key to the room where sensitive archival data are stored, instead of issuing a specifically requested dossier. Of course, if that key gets into the hands of the bad guys, the entire archive is exposed.
In the case of the APIs, the exploit is often performed by sniffing the traffic before it connects to the client where the filtering logic is implemented, thus getting access to unauthorized data.
Example
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”:”xxxxbbbbb”,”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.
What To Do
⢠Do not expect or rely on the client-side data filtering
⢠Minimize the use of to_json() and to_string() and the like functions that return the broad swath of properties.
⢠Individually review API calls that might return sensitive information such as PII, passwords, financial data or account names
⢠Implement output validation for APIs, including errors API returns.
API4:2019 – Lack of Resources & Rate Limiting
Without rate limiting, the application can be brought down by a Denial of Service (DoS) and similar attacks. This can be a lack of resources allocation limit as well as issues with the API behavior / application logic such as the size of payloads or the number or API request per second.
Example
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.
What to do
⢠Implement limits on the system resources an API can request, such as CPU, process handles, file descriptors, memory, etc. For example, this can be set at a container level.
⢠Implement rate-limiting for requests per second, restarts, the number of records returned with a single call and so on. Notify the user if the rates are exceeded.
API5:2019 – Broken Function Level Authorization
In many cases APIs expose administrative functions – new users and resources can be provisioned, configuration changes can be made and so on. If these are accessed by malicious users without authorization it can lead to much damage.
Lack of authorization at the functional level is an issue for many applications and systems, but it is even more pronounced in the case of APIs. APIs structured nature makes it easier for an attacker to guess the syntax and the verb of a potential endpoint to be exploited.
(e.g., replacing the HTTP method from GET to PUT, or changing the âusersâ string in the URL to “admins”).
Example
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â}
What To Do
- Implement Least Priviledge Access Control model with all access denied unless specifically granted to a specific user role or hierarchy.
- Limit unrestricted administrative access and make sure the userâs group and role are checked when a new user is provisioned or new privileges are granted.
API6:2019 – Mass Assignment
This is a risk of an implementation that uses APIs to modify the properties of an object without validating what the actual property is or how sensitive it might be.
Consider an IT admin setting an employee cubicle location, and then the same API allowing the salary information to be modified.
With this vulnerability, an attacker could gain access to object properties that they should not be able to modify.
Example
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.
What To Do
- Implement input validation; define and enforce what the input data are expect to look like. If possible, avoid putting input data directly into internal objects.
- Blacklist properties that should not be acessed by the clinet. Avoid âDropAllTable Bobbyâ situation.
API7:2019 – Security Misconfiguration
Security misconfiguration is the same risk as has been present in OWASP Top 10 for the applications for a long time. These can include a variety of configuration mistakes form misconfigured infrastructure access to bad network security to permissive HTTP headers.
Example
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 then attacker gained access to millions of records with PII, personal preferences, and authentication data.
What To Do
The API life cycle should include:
⢠Ensure the API and itâs environment such as cloud services and configuration files are properly locked down with restricted access
⢠Watch out for sensitive information being improperly exposed via error streams and exception traces. This can be exploited by attackers to discover schemas and get other valuable information
⢠Implement white lists for proper http verbs for each API endpoint and Cross-Origin Resource Sharing (CORS) policy for externally accessible endpoints.
API8:2019 – Injection
PUT and similar commands are often used to provide external data into the application. These data can represent direct input, metadata, a name of a function for execution, such as is the case with serverless computing and many other data types.
Without proper input validation this can result in SQL, NoSQL, Command and other Injections A malicious user can send data to trick the interpreter into executing data access or other commands that they shouldnât have access to.
Example
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)’
What To Do
⢠Implement rigorous input validation; Sanitize all external data, whether from third-party systems or provided by the clients.
⢠Watch out for special characters as these can be exploited to insert commands into data stream. Make sure the special character escaping mechanism is compatible with your interpreter
⢠Implement a parameterized interface with strict data typing and defined patterns for all string parameters.
API9:2019 – Improper Assets Management
Forgotten, unpatched and poorly secured assets have long represented significant vulnerability to enterprise systems. With APIs, it may be easier than ever to exploit the unmanaged assets and endpoints. Not only these may have security misconfigurations as described in API7, but additionally, they may have APIs of an old or deprecated version which can lead to an attacker being able to gain access to sensitive data or even take over the orphan asset.
Example
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.
What To Do
⢠Inventory all assets, servers, hosts, and integrated services, mapping each to the correct environment (development, testing, staging, production, recovery, etc.) Mark the assets that are API accessible from outside the organization.
⢠As much as possible generate documentation automatically; Include the documentation build in your CI/CD pipeline.
⢠Protect external AND internal APIs with a WAF that understand API payloads and is capable of parsing and interpreting the protocols your APIs use. Wallarm solution would work well for this use case.
API10:2019 – Insufficient Logging & Monitoring
Without monitoring of critical activity on the APIs, an attack in progress may not be detected in time or ever. In fact, statistically, it takes an organization over 50 days to detect an attack.
Having the logging and monitoring systems in place and properly tieing them to the alerting systems, security operation centers (SOC) and SIEMs goes a long way to reducing the window of vulnerability.
Example
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.
What To Do
⢠Use a centralized SIEM or a log management solution to log all structural events (new assets, new users, privilege changes) as well as failed authentication attempts, denied access, and input validation errors.
⢠Mask sensitive and PII data in the logs or treat the logs as sensitive data,
⢠Use a monitoring system with alerts and business-specific dashboards to be alerted about suspicious activities and attacks in progress in real-time and improve incident response.
If you, like us, appreciate the work the team has done on this initial version of OWASP API Top 10, get involved. The team is opening a call for data. Letâs make the APIs safer.
