API OWASP Top 10

What is an API

API is an acronym for Application Programming Interface. An API acts as middleman who delivers your request to the provider and then delivers the response to the requester. You can think of it as a code that allows two software programs to communicate with each other. It is like an interface that allows your application to interact with an external service using a simple set of commands. For instance when you click “Add to cart”, the API tells the site that you added a product to your cart. The website then puts the product in your cart, and your cart is updated. To make it easier to understand imagine you’re sitting at a table in a restaurant with a menu of choices to order from. Here the waiter is the most important link to communicate your order to the kitchen and deliver your food back to your table. The waiter is the messenger — or API — that takes your request or order and informs the people at the kitchen what to do. Then the waiter delivers the food back to you.

APIs are almost everywhere, right from searching about the weather in Google, logging-in with Facebook, paying with PayPal up to interacting with a twitter bot.

Over the years, this very same API has become an indispensable part of many of the businesses making their life simpler. The role of APIs is quite noteworthy if we look at it not only from the software development angle but also from the business collaboration angle. More than 60 percent of the participants in the Current State of API Integration 2018 report agreed that API integration is critical to their business strategy. The study also suggested over 50 percent of all businesses would partner via APIs.

By nature, APIs expose sensitive data such as Personally Identifiable Information (PII), which makes them a prime target for attackers. Without securing the APIs, rapid innovation is definitely a distant dream.

OWASP API Top 10

The tremendous technological advances and the need for rapid innovation have made it necessary to address the security concerns revolving around APIs. This has further resulted in OWASP launching a separate project dedicated purely on API security. The OWASP API Security Top 10 project focuses on the top ten vulnerabilities related to API security.

In this article we will be focusing on the top 5 vulnerabilities and how to prevent them. Remaining 5 vulnerabilities would be covered in the upcoming article.

So stay tuned! :-)

API 1: 2019 — Broken Object Level Authorization

This vulnerability can be seen while using IDs to retrieve information from APIs. Generally APIs track the identity of a particular user by using the user ID present in the API request. Though this might be useful in quickly identifying the session, it is not worth trusting the embedded ID completely. The attacker can substitute another user’s ID in the request to collect the required information.

For Example:

· Consider a situation where you are logged into your bank account and you request to view your financial information. Now, if the back-end doesn’t properly check for authentication or authorization then an attacker can use a different account to mimic the API call to access your account information by using the exposed object identifier.

· Yet another example to explain this would be an example API from Facebook, where we get the details using an ID:

\> curl -i -X GET “https://graph.facebook.com/{user-id}?

fields=id,name&access_token={your-user-access-token}”

Here we use the user-ID in the request as a parameter to get details of the respective user. Unless Facebook performs authorizations to check if the consumer of the API has permissions to access details of the user to whom the ID belongs to, an attacker can gain access to details of any user.

· In News: Information of roughly 2 million Verizon Pay Monthly customers was exposed due to IDOR (Insecure Direct Object Reference) flaw. The exposed information included full name, address, phone numbers, model and serial number of the acquired device, and the customer’s signature.[1]

How to prevent it:

· Implement an authorization mechanism that relies on user policies and hierarchies

· Do not rely on Ids sent by the client. Instead use the one in the session object

· Check for authorization for each client request that needs to access the database

· User random Ids that cannot be guessed (UUIDs)

API 2: 2019 — Broken User Authentication

Broken User Authentication means when the API Authentication system is faulty and poorly implemented which can allow attackers to assume other user’s identities.

For example:

• If weak API keys are being used and they are not rotated, using weak plain text or encrypted, poorly hashed and shared/default passwords.
• There are credentials and keys in the URL.
• Non-expiring, unsigned or weakly signed JWTs.
• Session values do not time-out or get invalidated after logout.

Consider a scenario where the API is using an unsigned or weakly signed JWT (Json Web Token) for authentication, an attacker can edit the token and set the privileges to admin.

JWT for non-admin account :

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJuYW1lIjoiSm9obiBEb2UiLCJwcml2ZWxlZ2UiOiJub24tYWRtaW4ifQ.EQxK_FOlotTQhQXAZ0BaYZ2TqbtjbJIuHhYRD0FqvFc

ALGORITHM & TOKEN TYPE:

{

“alg”: “HS256”,

“typ”: “JWT”

}

DATA:

{

“name” : “John Doe”,

“Privilege”: “non-admin”

}

Now the attacker can edit the token data and it is known that the name of the admin is Greg Kennedy, so the attacker can change the DATA header in the JWT.

DATA:

{

“name” : “Greg Kennedy”,

“Privilege” : “admin”

}

The new JWT is:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJuYW1lIjoiR3JlZyBLZW5uZWR5IiwicHJpdmVsZWdlIjoiYWRtaW4ifQ.e2vkrwRy53z9gSUMA0W-nmZxqAaCSZut_bg0fubwbfM

Now the attacker is able to login as Greg Kennedy, the admin.

How to prevent it:

· In terms of brute force, rate limiting and lockout protections the forget password endpoints should be treated as login endpoints

· Where possible implement multi-factor authentication

· Implement anti-brute force mechanisms

· Implement weak password checks, lockout policies and stricter rate limiting for authentication

· Don’t confuse OAuth with authentication, OAuth is not authentication, it’s an authorization protocol, or, better yet, a delegation protocol and neither is API keys.

API 3: 2019 — Excessive Data Exposure

APIs should only return the data which is relevant and required by its consumers. Excessive data exposure is a vulnerability that does not protect user’s information from servers such as profile name, passwords and any other personal information which should not be publicly accessible.

For Example:

· When a user request his profile information from server, the server should respond with the particular requested users information but due to this vulnerability server will respond all the users information available in that database that leads to excessive data exposure.

· In News: Security glitch in the group dating app 3fun, revealed details of users in Downing Street and White House.[2]

How to prevent it:

• Responses from the API should be reviewed to make sure they contain only legitimate data.
• Avoid relying on the client side to filter sensitive data.

API 4:2019 — Lack of Resources & Rate Limiting

The attacker wishes to do a DoS attack (Denial of Service), exploitation requires sending simple API requests over and over again.

Quite often APIs do not put any restrictions on the size or number of resources that can be requested by the client. This not only impacts the API server performance, leading to DoS, but also makes it vulnerable to brute force attacks.

For example:

· Consider a scenario where the application contains a list of users with a limit of 100 users per page. The user list is retrieved by issuing a GET request to “/api/users?page=1&size=100”. Now if the attacker changes the value of the parameter size to 9999, it can make the API unresponsive and also make it unavailable to handle requests from other users at the time (DoS).

· For instance when a large image is uploaded by issuing a POST request to /api/v1/images, API creates multiple thumbnails of different sizes. During this the memory is exhausted due to the image size and the API becomes unresponsive.

· Unpacking of “zip bombs” takes excessive amount of resources and overloads the API.

· In News: Lack of rate limiting coupled with a poor default password system exposed Zoom private meetings to Cyber Attacks.[3]

How to prevent it:

• Use of docker can help control and reduce the memory and CPU usage.
• Define proper rate limiting and how often a client can call the API within a defined timeframe.
• Proper server-side validation for the request parameters to handle the malicious use cases.

API 5: 2019 — Broken Function Level Authorization

Broken function level authorization is when an API fails to perform checks on the user’s permissions before granting them access to protected functionality. This vulnerability is due to the lack of authorization at more granular level of an API. The numerous user groups, roles and different hierarchies lead to an unclear separation between administrative and regular functions. These authorization flaws when left exposed can be exploited by the attackers to gain access to other user’s resources or administrative functions.

For example:

· An API can consist of multiple operations for example, GET /users/{user-id} for retrieving user information and a DELETE /users/{user-id} for removing a particular user profile. Authorization for this API should be done by operation, not just at an API level. If authorization is performed at an API level, it results in anyone having permissions to retrieve user information (GET) and also to remove user information (DELETE), which isn’t correct.

· Consider an API having an endpoint which 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 knows this API structure takes an educated guess and manages to access this endpoint, which exposes sensitive details of the users of the application. This failure to check permissions on a per-function level makes the API vulnerable to attack.

How to prevent it:

· Deny all access by default.

· Allow operations to users belonging to the appropriate group or role only.

· Make sure that the administrative functions implement authorization checks based on the user’s group and role.

Conclusion:

We have tried our best to explain the above five risks to the best of our capability in the simplest way possible and we hope you liked it. One thing to note is that the attack scenarios are just some of the endless possibilities that exist when exploiting vulnerable APIs. The risks mentioned above can be easily tackled if organizations improve their secure coding practices, more specifically in terms of handling APIs.

Stay tuned for the next article covering the remaining 5 API vulnerabilities.

Stay home. Stay safe.

By

Anu Bhakhtadas

Siddhant Chouhan

Cyber Security Researchers @ Andy InfoSec

Part 2 published here