OWASP API Security Top 10 - Circumventing Broken Object Level Authorization and Excessive Data Exposure

[nathanaw]

Hi all, I refer to https://raw.githubusercontent.com/OWASP/API-Security/master/2019/en/dist/owasp-api-security-top-10.p...

Specifically, I am concerned with Broken Object Level Authorization and Excessive Data Exposure where Broken Object Level Authorization means someone rogue who has API access could access objects which they should not be privy to.

Understand that others such as "Lack of Resources & Rate Limiting" can be achieved through Apigee quota, spike arrest, policies etc.

However, my primary and foremost concern is still Broken Object Level Authorization and Excessive Data Exposure.

Other than programmatic controlling the access to the object such as User A can only request for Object A, how can we achieve fine grain object level authorization through Apigee?

Thank you.

Regards,

Nathan Aw

https://sg.linkedin.com/in/awnathan

[inon · Accepted solution]

Hi @Nathan Aw,

I'm a co-leader of the OWASP API Security Project.

BOLA (Broken Object Level Authorization), and Excessive Data Exposure are great examples for API security issues.

BOLA is a vulnerability that should be fixed in the code level. In order to solve BOLA you need a deep understanding of the AuthZ mechanism, correlations between users --> resources and user's policies and roles.
There are two types of BOLA - based on user ID or based on object ID. To learn more about BOLA, the different types and why it becomes such a big issue in API security, please check my article:

https://medium.com/@inonst/a-deep-dive-on-the-most-critical-api-vulnerability-bola-1342224ec3f2

Current security solutions in the market (including API gateways) don't have a deep enough understanding of the business logic of the app and user's policies to mitigate BOLA and Excessive Data Exposure.

Please feel free to follow me on twitter to get more updates and tips about BOLA and the OWASP Top 10 for APIs 🙂

[inon · Accepted solution]

Hi @Nathan Aw,

I'm a co-leader of the OWASP API Security Project.

BOLA (Broken Object Level Authorization), and Excessive Data Exposure are great examples for API security issues.

BOLA is a vulnerability that should be fixed in the code level. In order to solve BOLA you need a deep understanding of the AuthZ mechanism, correlations between users --> resources and user's policies and roles.
There are two types of BOLA - based on user ID or based on object ID. To learn more about BOLA, the different types and why it becomes such a big issue in API security, please check my article:

https://medium.com/@inonst/a-deep-dive-on-the-most-critical-api-vulnerability-bola-1342224ec3f2

Current security solutions in the market (including API gateways) don't have a deep enough understanding of the business logic of the app and user's policies to mitigate BOLA and Excessive Data Exposure.

Please feel free to follow me on twitter to get more updates and tips about BOLA and the OWASP Top 10 for APIs 🙂

[nathanaw]

Sure, will follow. How can such granular matrix authorisations be achieved? Are there any out of the box tools for that? Writing it in code will be very challenging.

[nathanaw]

if there is some form of opensource authorisation matrix tool that will be useful to deter aginst BOLA in a configuration way manner, it will go a long way for maintainability. Imagine BOLA can only be deterred programmatically, it will be difficult to maintain/audit.

Are there tools such as OWASP ZAP to test for BOLA?

[inon · Accepted solution]

@Nathan Aw

That's a great question. I've seen some vendors that handle BOLA in different ways.

* RASP - Some RASP solutions, (Sqreen for example) in order to mitigate the problem, will alert you on enumeration attempts: too many calls to a specific API endpoint. It doesn't prevent the problem.

* Scanners - I heard that Tinfoil security can scan against this type of issue, but I didn't check it myself.

* Hdiv security - they have some type of solution, but for my understanding, it doesn't work with APIs.

Also, when you search for more details about the problem, it's good to remember that some people refer to it as "IDOR" (Insecure Direct Object Reference)

----

It's really hard to solve BOLA out of the box because of the fact that authorization is complex.

Let me share with you an example:

If we take a ride-sharing app, there are many sensitive resources that are being exposed.

One of them is "trips". You can access the details of the trips you've taken using the following API endpoint: `/api/v1/trips/<trip_id>`

How can we make a decision if user X should be able to access trip Y? It totally depends on the business logic of the app and it's not easy to figure it out out of the box.

* Let's say that you share the ride with a friend, and split the payment. Both of you should have full access to the trip details (one trip --> two users)

* What happens when the app hooks you up with a random co-rider (Uber pool)? you both should be able to access the trip, but the API shouldn't expose all of your details to the other rider.

* What happens if you're a regional admin on the Uber app? you might be able to access all the trip objects in your region (North California) but you should be able to access trips in different geo-locations (NYC).

An out of the box solution to solve/find this type of problem needs to understand all of these cases, and that's not easy.

[nathanaw]

I did a presentation on this topic at OWASP Singapore. https://owasp.org/www-chapter-singapore/assets/presos/Securing_your_APIs_-_OWASP_API_Top_10_2019,_Re...