OWASP API Top 10 for Dummies — Part #1
Introduction
In this blog series I will try to explain the most common threats for APIs using simple analogies.
I started thinking about writing this blog last time I was visiting my grandfather. He asked me — “Inon, what do you do for work?”. Simple answers like “Cybersecurity” didn’t tell him much. He was eager to understand more..
Explaining complex concepts, such as Authorization and API Sprawl to an older person who didn’t grow up in the internet era was a challenge. But I ended up finding some real-world examples from daily life situations that shed some light on the spooky world of API threats.
API #1 — Broken Object Level Authorization (BOLA)
Imagine that you go to a club on Saturday night in San Francisco. The fog has rolled in and it’s pretty chilly, so you bring a warm jacket. Once you’re in the door, you want to ditch your jacket so it doesn’t get in the way of mingling and enjoying the night. So you head to the coat check.
At the coat check, you meet James who takes your jacket and hands you a ticket with a number on it — #26. James then takes your jacket and hangs it on the rack with jackets from all the other club-goers.
You head off into the club to have a few drinks and dance the night away.
After about an hour and a few drinks you realize this is not your scene and you get tired of yelling over the loud music to try to start conversations. Boredom and a bit of deviousness kicks in and you decide to use a pen to change the number on your coat check ticket from #26 to #28. It looks passable.
Back at the coat check you hand the altered ticket to James, who doesn’t bat an eye as he reaches to the rack to grab jacket #28. You’re in luck, instead of your cheap old jacket #28 is a fancy Chanel jacket and it’s just your size.
What you just did is basically equivalent to the BOLA exploit:
- The coat check room is the vulnerable API endpoint.
- James is the vulnerable code who doesn’t implement authorization checks.
- The jacket is the exposed object.
Now that you know this trick, you can just print fake tickets with all the numbers from 1–100 and steal everyone’s jacket. Evil, right?
API #2 — Broken User Authentication
A simple way to explain Broken User Authentication is simply with one of these lovely combination locks.
We all use them in the gym lockers for example. You spent $5 on Amazon to get your fancy lock. Now it’s time to set your access code, place your belongings inside the locker and trust this metallic masterpiece to protect against thefts.
While they might provide some protection against lazy thieves, they are not going to be very successful against the more ambitious ones.
Let’s review some of the problems they have:
- The “access code” has only 1000 possible combinations. It doesn’t take more than one second to try a single one. A patient thief can enumerate all the possibilities in less than 20 minutes.
- You can choose any combination you’d like, even the most trivial ones, such as “0000” or “1234” — which makes the thief’s life very easy.
- You can listen to the ticks and figure out the access code
Considering these weak points, you shouldn’t use these types of locks in a dangerous environment to protect your important assets.
The internet is a very dangerous environment, so if your API is publicly exposed — you must have a strong “authentication lock” to protect it.
Unfortunately, many authentication mechanisms in APIs:
- Allow weak passwords
- Don’t limit the number of attempts a single user can try a user & password combo
- Have weak configuration or known implementation problems
API #3 — Excessive Data Exposure
To explain Excessive Data Exposure, I would like to share with you a story about Ron.
In the city where I grew up, we had a pretty decent library. The librarian was a lovely older guy named Ron. Ron was the type of person who knew everything that was going around him — including the most exciting gossip.
One time, my friend, Ariel, asked me to return a book on her behalf because she went on a long trip with her family. When I arrived at the library, Ron asked if I knew the member ID of Ariel, but I didn’t.
Then he asked me for her full name, ran a quick search, and found 3 different members with the same name. Looking at his screen, he saw the full details of each member, and asked me “is that the one who lives in address X or address Y”? “Is her birthday on May 5th or August 10th?”
After I replied to his questions, we found the right member ID, but Ron couldn’t help himself and started sharing with me the recent news about Ariel and her family:
Apparently he saw her holding hands with Sarah (whom I had a crush on 🥲), and also shared with me how much her family had spent on their vacation! This guy literally knew EVERYTHING.
APIs often have Rons — sneaky gossipy API Endpoints that look innocent, have access to a lot of information, and share too much with their users, even though they are not supposed to.
Learn more in the next blogpost: OWASP API Top 10 for Dummies — part #2
