Team Traceable 
Smart companies use APIs to serve their clients. Whether the user is using a web browser or a mobile app, they’re probably talking to an API. They make it easier to upgrade the user experience, add new products, and talk to new businesses and new markets.
But APIs introduce security issues, too. When you give a hacker an interface, they make it do things you never expected.
Let’s talk about API exploits. What are they? How are they different from vulnerabilities? How can you avoid them?
What is an API Exploit?
An API exploit is a technique or program that takes advantage of a vulnerability. It’s a way to steal data from, gain access to, or attack a service. The difference between an API vulnerability and an API exploit is one is the weakness while the other is the weapon.
A vulnerability is a deficiency that provides a way for attackers to make an API do something that the designer didn’t expect. An exploit is a method for using it. So, before we talk about exploits, let’s talk about the most common API vulnerabilities, and why exploits are often very simple techniques and programs.
What Are the Most Common API Vulnerabilities?
For a list of the most common API vulnerabilities, we can go to the Open Web Application Security Project (OWASP.) They publish a list of the top ten API Security issues. These risks are an excellent guide to how to find and fix API weaknesses.
Let’s look at the top three API vulnerabilities, according to OWASP.
Broken Object Level Authorization (BOLA)
BOLA is when an API client can access data they shouldn’t be able to. According to OWASP, it’s the most common API security problem. It’s also a potentially serious issue. This happens when an API authenticates a user, but doesn’t verify what they should be allowed to do after the service authenticates them.
So, if a user requests an object and the API doesn’t verify whether they should have access to it, that’s BOLA. Depending on the nature of the API and the vulnerability, this can lead to data theft, modification, or deletion.
Exploiting this vulnerability doesn’t require any code hacks or password thefts. If an attacker is aware of the problem, they only need an authenticated connection and code to make the requests.
Broken User Authentication
When you implement an authentication mechanism incorrectly, attackers can gain access to an API by impersonating a valid user.
Some common issues are:
- Passwords stored in plain text or hashed incorrectly.
- Improper handling of authentication headers.
- Allowing weak passwords that make an API vulnerable to dictionary attacks.
- Mishandling repeated login failures, which also leaves a connection open to dictionary attacks.
Excessive Data Exposure
When an API responds to a request with more data than necessary, it’s an excessive data exposure vulnerability. This often happens when more than one application shares an API, and the API relies on the clients to filter the data they need.
For example, a mobile app for users and a web application for administrators share an API. When an administrator requests a list of users, they can see email addresses so they can contact users. When a user does, they only see a name and link to send an in-app message. But, since they share an API, the API relies on the mobile app to hide the email field. So, in this example, a hacker with a mobile user account can easily steal email addresses.
Exploiting API Vulnerabilities
How would an attacker go about crafting an exploit for these three types of vulnerabilities? Let’s look at an example.
A Broken Object Level Authorization Exploit
Imagine an API that exposes user information via a RESTful API. It’s an ecommerce site where people can purchase products.
It represents a user with a JSON object like this:
{
“id”: 1,
“fullName”: “First Last”,
“streetAddress”: “123 Elm St.”,
“state”: “DE”,
“zip”: “01234”
“email”: “foo@example.com”
}
The API offers endpoints with typical verbs for CRUD operations:
- GET /people/ with no argument retrieves a list of all users.
- PUT /people/{ID} with a JSON record, updates an existing user with new information.
- POST /people/ with a JSON record to add a new user.
- GET /people/{ID} to retrieve a user by Id.
- DELETE /people/{ID} deletes a user.
The API increments user ids as clients add them. In other words, the user ids are integers and they are sequential.
So, the first exploit a hacker could write for this site would be to request users, starting at “1” and stopping at an arbitrary number.
Let’s use pseudocode for this:
login to site
j=1
while j < 1001
info = GET https://www.example.com/people/j
save info
j++
wend
This would retrieve the first 1000 users and store their information.
If the attacker stopped right here, they would already have up to 1000 emails and home addresses for users.
But if this API suffers from a BOLA vulnerability, they can change user records, too. What if they changed the email addresses on the accounts so we could reset their passwords and home addresses? They could then force a password reset, login, and use the hacked accounts to buy goods.
login to site
j=1
while j < 1001
request =
{
id: j
“fullname”: name from saved data
“streetAddress”: “123 Maple St.”,
“state”: “XX”,
“zip”: “XXXXX”
“email”: “XX@example.com”
}
result = PUT /https://www.example.com/people/
wend
Now they have user records that are associated with someone else’s credit cards.
This is a contrived example, but it shows how exploiting many API vulnerabilities is relatively simple and can be done with a small Python or Bash script.
Preventing API Exploits
Creating API exploits is easy. Avoiding the most common ones can be relatively simple, too.
Here are a few API best practices:
- Principle of least privilege – if a user is not explicitly allowed to perform an action, the API should prohibit it. In the example above, a single user could retrieve every user’s information and then alter it. They should even be allowed to perform the first step.
- Verify permissions on every function – similar to the first principle, your API should check user entitlements on every operation they perform, whether it’s reading, writing, creating, or deleting a record.
- Prevent brute force attacks – if a user repeatedly fails to enter the right password, time out their account, present a CAPTCHA, or both. Dictionary attacks are still a threat, even if you check your user’s password for complexity.
- Implement two-factor authentication – Enough said.
- Use different APIs for different applications – the easiest way to avoid excessive data exposure it to create different APIs with different data dictionaries for each of your apps.
- Filter fields based on permissions – the hard way to avoid excessive data exposure is to implement field filtering as part of entitlements.
These six steps will go a long way toward cutting off the most common exploits. OWASP has more recommendations linked to their top ten vulnerability list.
Protect Yourself From API Exploits
We’ve covered what API exploits are. We started by comparing them to API vulnerabilities and explaining how an exploit leverages a vulnerability to gain access to or even alter data. Then we went through a pseudocode example that showed how easy it is to create an exploit. Finally, we wrapped up with a few best practices.
Traceable AI has tools that will help you secure your APIs. View a demo or book a session to learn more about how Traceable AI can meet your API catalog, observability, and security requirements.
This post was written by Eric Goebelbecker. Eric has worked in the financial markets in New York City for 25 years, developing infrastructure for market data and financial information exchange (FIX) protocol networks. He loves to talk about what makes teams effective (or not so effective!).
