OWASP API Top 10 for Dummies — Part #2
Welcome back to our blog series on the OWASP API Top 10! This is continued from Part I. If you haven’t read the first part, check it out! These blogs are written for a non-technical audience, and are meant to give fun analogies to explain, what are often, some challenging technical concepts.
In Part II, we tackle Lack of Rate Limiting, Broken Function Level Authorization (BFLA), and Mass Assignment.
Let’s get started.
API #4 — Lack of Rate Limiting
Let’s say that you were tasked to develop a system to manage a bank’s customer information.
As the system architect, It’s important to understand that some features are more sensitive than others and require special care in terms of rate limiting. There are various reasons why:
- The “Check customer’s credit score” feature is expensive — the bank has to pay the credit bureau for each credit check.
- The “Download customer’s annual report” has high computational needs to generate such a report.
If a banker uses one of these features, it’s completely legit — because she is supposed to have access to it.
But what happens when the banker decides to run credit checks for 100 customers in one minute? Or perhaps generates an annual report for all the customers of the branch at once?
This is where the problems begin. Just because one has access to a feature, doesn’t mean they should access it relentlessly. The system architect has to limit the access to the sensitive features.
An API might expose hundreds of endpoints, where the majority of them are non-sensitive in terms of rate limiting. It’s important to understand the business logic of the app, and based on that, implement rate limiting rules.
For example:
- A banker can not access “download annual report” more than 10 times an hour.
- An e-commerce platform should not allow a user to access the “check coupon code” API Endpoint more than 5 times — or otherwise an attacker would be able to enumerate coupon codes and get free stuff.
API #5 — Broken Function Level Authorization (BFLA)
During my military service, I was part of the “Red Team” of the IDF.
It had two main impacts on my life:
- I used to work with different teams, trying to find vulnerabilities in their systems and helping to fix them.
- Every few weeks I would have a project at a different military base, and would have to switch my go-to cafeteria.
As you can imagine, as a 20~ years old soldier, my main concern in life was where I could get the best meal. As a foot soldier, I had to exploit BFLA from time to time in order to eat in the best cafeterias.
For example, in one of my projects I was sent to a navy base in the south of Israel.
The clock turned 12pm, and it was time to get lunch.
I was disappointed to find two different lines — one to the “foot soldiers” cafeteria and the other to the “higher-ranking officers” cafeteria. There was a guy checking each soldier’s tag to make sure they entered the right place.
Fortunately, the guy had a name tag on his uniform. I approached him without thinking , put on my most surprised face, gave him a huge hug and told him “Ben!!! I can’t believe I’m seeing you after so long. This is so exciting. How is your brother doing?”
Before he even had a chance to respond, I told him, “I have to get in before they run out of Schnitzel, but I’ll come to catch up later”. Then I simply entered the fancy cafeteria with a group of friends.
Most of the APIs I have tested have at least one Ben — an API Endpoint that is supposed to be accessed only by high-privileged users (such as major generals or super admins), but they fail to validate that the user actually belongs to this group.
Mitigation
To avoid BFLA when writing a new API Endpoint, developers should always ask themselves “which types of users should be able to access this Endpoint?”, and implement authorization checks in the code or in the configuration to prevent unauthorized function access.
API #6 — Mass Assignment
I want to share with you a story I’ve heard from a good friend. There is a city in the US, let’s say it’s called “Narnia” for the story, with a big community of Israelis. There used to be only one direct flight between Narnia and Tel Aviv. At some point, another airline, “Aslan”, recognized the opportunity and decided to launch their own direct flights. To promote the exciting move, executives from “Aslan” set up a meetup with the Israeli community in order to see how they could attract more people to use the new route. During this meeting, one of the concerns brought up by the Israelis was that if they moved to Aslan, they wouldn’t be able to maintain their Frequent Flier Program (FFP) status.
At the end of the meeting, three representatives from Aslan were signing people for their FFP, with the promise that new customers who already had a status with the first airline would receive the same level if they joined on that same day.
Two out of the three representatives actually used a system to verify the current status of the new registrants. The other one, Amit, was a bit more chill about it — he just let the people fill out a form: name, email and current status. I’m not implying that anybody did it, but, it was theoretically possible to join Aslan as a new frequent flier and get the highest status, even if you didn’t have any previous status with the first airline.
During the registration process, a new customer should be able to set some properties directly — such as email or food allergies. Other properties, such as “FFP status” or “gained miles” should never be accessed directly by the customer.
In a New Relic vulnerability, James Kettle found an Amit in the code.
As part of an “update settings” flow, an attacker was able to set the “api_access” property, even though they were not supposed to have access to it. Then he gained access to the New Relic API without paying for it.
