10 most common API security attacks

APIs are the new most popular way to make complex and scalable web applications. According to the community forum programmableweb.com in 2015 they have listed 12,000 APIs in their directory, and in early 2019 they discovered that the number has gone to nearly 22,000, which prove the rapid growth in their use.

For this reason, the recent attacks against such apps are increasing in a dangerous way. In this post, I will explain with practical examples 10 most critical API security vulnerabilities that you need to check in your API or think about while developing it according to the OWASP TOP 10 and how you can fix them.

Broken Object Level Authorization

The broken Object-level authorization vulnerability is one of the most popular vulnerabilities in not only API but in all web applications. Let me first explain it for you, actually, this vulnerability happens, when the user is able to manipulate his inputs to perform some unauthorized actions on some objects in the app.

Let me give you a simple example to understand this …

Let us suppose that there is a parameter in the app that represents a user id, and that this parameter is sent to the app when the user tries to modify his profile (This is a real example that I have discovered in one of my clients API). When the attacker changes the id by intercepting or directly modifying the request, he was able to modify the legitimate user information without logically having the right to do so.

One more practical example to better understand the danger of this vulnerability … a shopping app, was sending the buyer id when he clicks on the history button to list all his past purchases.

{“action”:”purchases”,”user_id”:”[userid]”}

So by intercepting the request and changing the userid value, the attack was able to list any user’s past purchases. Which in this case would be a disaster to the website, as this would leak some very important information about what works for them.

Now to protect your API from this attack you would need to do the following :

1. Before doing anything in the app, even before showing any page for the user, you need to check if the user is authenticated first.
2. Always check the user permissions before performing any action on the app.

Never trust user inputs

Broken User Authentication

Broken User Authentication happens when the developer forget to check if a user is authenticated in the app before displaying a page or doing an action in the app.

To be honest, the broken user authentication kind of vulnerabilities is very rare on the web. I have performed a lot of penetration tests against APIs and I have found this kind of vulnerability in a very few numbers of APIs.

However, if the OWASP TOP 10 has this type of vulnerability in the second place then, it is something very popular. Maybe, I did not found any of them because the security level in the APIs that I have tested was very good.

Anyway, as I said before for the broken object level authorization, to fix this vulnerability you need to always check that the user is authenticated before executing any action in the app.

In my opinion, this kind of vulnerability happens not because the developer doesn’t know about it, but simply because the authentication process a specially in APIs is very complex and sometimes they just miss some pages and forget about it.

Excessive Data Exposure

Excessive Data Exposure happens when the APIs show more data than expected, and by the way, this is something very popular in APIs. This type of vulnerability is popular because APIs are considered a source of data and developers rely on the client-side code to do the filtering. 

Let me give you some real examples of this vulnerability. A library mobile app I have tested once gives his clients the ability to rent books and receive them directly to their homes. When the client chooses a book, the app displays the description of the book and if it is already rented or not, and when he will be returned. That is all what is displayed in the mobile app.

However, when intercepting the API responses I have discovered that it was giving even information about the user id that has rented the book, when and the email address of that person. This is a very dangerous data exposure rather than to the API system or the business.

Knowing who rented what, gives the attacker the ability to better understand what is actually working in the library and what books he needs to buy and which audience to target with an already established email list. Even worst, the exposed email addresses give the attacker the possibility to perform what we called, a Bruteforce attack against the authentication system to hack the user’s accounts.

To fix this vulnerability you will need to perform all your data filtration at the backend level, while always taking in consideration the user permissions and authentication.

Lack of Resources & Rate Limiting

Now here is something I always see when I do an API penetration test, no Rate limiting. After years of experience in pentesting I think this is the most popular vulnerability between all the APIs that I have tested.

This vulnerability happens, when the API does not limit the number of requests that a client could request per day or per hours or … Unfortunately, this gives the bad users the possibility to perform many other types of attacks. Additionally, this type of vulnerability has also impact on business success and I will explain this in the next paragraphs.

Before I start talking about the business impact of this type of vulnerability, let me first explain their technical possible exploitation and their impacts on the API. Not limiting the client requests in the API per day, hours or second, gives the attack the possibility to perform for example a Bruteforce attack against the authentication system. I have already mentioned this attack in the last explained vulnerability.

A Bruteforce attack is a technique where the hacker try to test multiple combinations of username and password to try to hack some user accounts.

Here is a realistic example of when this type of vulnerability is considered very dangerous and could lead to some critical information leak. Let us say you have a folder where you put for example the user’s passports or signature images. The images once uploaded by the client get a random unique string that has six-digit and chars. Of course the, public folder could not be listed (I will talk about that later …) but having this kind of vulnerability in your API gives the attacker the possibility to bruteforce the strings to get all the other users passports and signatures.

Now let’s see what is the business impact of this attack. Scrapping the data of the API is the first thing that an attacker could do with this vulnerability. Here is a real example, a mobile app that tells you the name of the phone number. If this vulnerability exists in this API, then an attacker could perform a bruteforce attack against the phone numbers and retrieve all the database of the API … I will let you imagine the business impact of such an attack.

To fix this vulnerability you will need to define a limit of the number of requests that a device or an IP address or a user could send per day, an hour, or even seconds. Most of the big APIs do this, and Instagram for example has a limit of 200 requests per hour.

Broken Function Level Authorization

The broken function-level authorization vulnerabilities happen when a simple user gets the ability to perform some actions that he does not have permission to do it. This vulnerability is also very popular and I have seen it in many APIs and even websites. This is why I always recommend my clients to perform a gray box penetration test. In this type of penetration test you get the possibility to perform horizontal and vertical tests that cover this type of vulnerabilities.

I am not saying that this cannot be tested in a Blackbox penetration test, but in most cases, it is missed due to not having this information about the app structure and privileges.

An example of such vulnerability that I have discovered while doing penetration tests. A web application was giving the administrator the possibility to change any user profile and accept/deny any user comment. Unfortunately, the backend API was suffering from this type of vulnerabilities. Therefore, the attack was able to accept all his comments without being an administrator. In addition to that, he was able to modify any user information.

The impact of this category of vulnerabilities, changes depending on the vulnerable action. I mean if after exploitation the simple user got the ability to change any user password, then the impact is full control over the app, and so on so forth.

Mass Assignment

The mass assignment vulnerability happens when the API trust too much the user inputs. To better understand this vulnerability let me give you a realistic example.

An API that gives users the possibility to test connectivity between the API and a website so that it can perform some actions between both of them. Now to test the connectivity, the API gives the users the possibility to perform a ping test, by just entering the IP address or the URL of the other website.

Then the API execute the following command to perform the ping :

ping –c 3 [user_input]

in this situation if the app is vulnerable to mass assignment, then the attacker would be able to inject the following code by any malicious command to take control of the host like following :

ping –c 3 www.example.com; ls

there is really many examples for this type of vulnerabilities depending on the business logic, the idea is to not ever trust the user input no matter what … to avoid this type of attacks.

Security Misconfiguration

To be honest this vulnerability concern more the network and system administrators. Actually, this vulnerability happens when the host where the API is running is not well secured or simply vulnerable which puts the API in danger. Let me give you an example of a vulnerable host.

1. A web server run under a vulnerable old operation system (OS) that has a remote code execution on it
2. Some services that run on the OS are vulnerable
3. The OS is misconfigured and give the possibility to list the API directories
4. …

So as I said this vulnerability concern more the Operation system where the API is running. So before putting your API in production, please ensure that the host that is going to run it is itself well secured and has the latest updates.

I also recommend using some web application firewalls to block some one-day attacks that may affect your website.

Just to give you a quick explanation for the word one-day. The one-day attacks or vulnerabilities are the vulnerabilities that was discovered by the vendor and they get exploited just the day after the vendor has released the patch to it.

Injection

And we get to the most famous vulnerability, that most developers know about, but little know how to fix it correctly. This vulnerability happens when as always the app trusts too much the user input and does not filter it before using it in a legitimate SQL, LDAP, or … request.

A simple example of the injection, is an API authentication system where the user send his username and password, then the API send the following request to the database to verify the user information:

SELECT * FROM users WHERE username=’[username_input]’ AND pass=’[user_password]’;

If the API is vulnerable to an SQL injection vulnerability, the attacker could send the following input to manipulate the legitimate SQL request :

Sql = ‘SELECT * FROM users WHERE username=’’ or ‘1’=’1’– AND pass=[user_password]’;

To be honest, year after year I notice that this kind of vulnerability is getting closer to his end. This end is getting closer to this specific type of vulnerability because all the development frameworks are now forcing the developers to correctly filter the user inputs before using them. In addition, most companies and clients are requiring their service providers to train their developers in secure development.

Here is also some sub types of the injection vulnerabilities:

• SQL injection
• LDAP injection
• NoSQL injection
• Command injection
• …

Improper Assets Management

In cybersecurity, we say that the security of a network depends on its weakest link. That’s exactly what this vulnerability is about. If you forget, only one API in your network without updates and with many vulnerabilities, then the security power of your system is equal to that API security. Simply because hacking this API lead to tacking all the others down.

Therefore, leaving an outdated API in your network is a vulnerability that we call improper Assets management and you need to fix it as soon as possible.

Even leaving the API documentation without update is actually an improper assets management as leaving it like this make the fixing of the vulnerabilities very difficult.

Insufficient Logging & Monitoring

Each time an API or a web application is published on the web the first thing that needs to be set up with the API is the logging and the monitoring. Simply because in this phase the API would have many bugs that will show after putting it in the production environment and a logging system is necessary to detect bugs. In addition, a monitoring system will not only keep you aware of the API goes down but also, if an attack happens at any moment you will be noticed as fast as possible.

The insufficient logging and monitoring is a vulnerability that could be solved not only by the API but also by the environment that hosts that API. Most web servers come with their own logging system. Unfortunately, this logging system does not give much information to trace back the problem of investigating deeply on it.

Therefore, installing or developing logging and monitoring in the API would be a very good plus in the API.