API-03 Broken Object Property Level Authorization

Another authorization flaw and this one is new to the OWASP API Top 10! It combines the older vulnerabilities Excessive Data Exposure and Mass Assignment into a single vulnerability. While Broken Object Level Authorization is at the Object level, so a single resource that can affect multiple objects (anyone can delete any book even if they don’t own it), this vulnerability is at the property level. 

In any API there are a few properties that we need to store, but we don’t necessarily want to be visible or editable in the same ways as others. For example before we allow a password or email to change we may want to confirm the current password to prevent account takeovers. Or we may want to show order information but not the credit card number associated with that order. API often allow properties and resources to be edited directly with CRUD (Create Read Update Delete) functionality such as the RESTful API endpoints. While we may want to expose some of the information that we later use in an application, we do not want these properties to be editable with the standard PUT request (Mass assignment) or visible on a GET request for a collection or an object (excessive data exposure). 

Suzy’s social is doing well and everyone is creating accounts and rushing to get valuable single character usernames and brands are making sure they grab their usernames too. While looking at the support information she notices every single character account has been hacked! And they all claim that they got a single notification of their password being changed twice and then login from a new location. One of the victims Viv who has the username @v is very upset as she was one of the first sign ups!

After looking at the logs Suzy begins to piece together what happened and the identity of the attacker, Adam. Adam was able to view Viv’s account information by visiting her profile seeing a GET request to /api/users/d000fccc-537f-4dfe-8969-0c35e15f4e02, which does show a password field but the data is unreadable, not great design but he has to go back to the drawing board! Because Suzy uses a modern RESTful API he deduces that there must be a PUT /api/users/d000fccc-537f-4dfe-8969-0c35e15f4e02 but it shows him a 403 error access denied! Suzy successfully managed to secure that endpoint from API1 Broken Object Level Authorization. He realises that his attack must come from Viv’s account and crafts a phishing email, this email reports the password being changed with a web page that will make the API request to PUT /api/users! As Viv panics and clicks on the link she sends the PUT request from her account via the malicious website. This time she gets another email as her password is changed and Adam successfully logs into the @v account.

In traditional web applications these kinds of attacks are limited, as people need to provide the current password before changing their password. APIs expose direct endpoints to edit properties of resources in the API. These endpoints can bypass and ignore any additional rules as client data is directly binded to the data source, usually through generated routes.

When designing APIs it is important that these automatically generated endpoints aren’t left, and that each route and property is fully designed and intentional. If you are using a framework you should investigate any built in solutions you can utilise such as the fillable attribute in Laravel, which only allows binding of specified properties. In general any automatic method for binding data from user input and the data model shouldn’t be used.

Harold Bell

Harold Bell is the Director of Content Marketing at Noname Security. He has over a decade of experience in the IT industry with leading organizations such as Cisco, Nutanix, and Rubrik, and has been featured as an executive ghostwriter in Forbes Technology Council and Hacker News.

All Harold Bell posts All of Harold Bell's posts