Broken Object Property Level Authorization to privilege escalation

Photo by Sigmund on Unsplash

Hi guys, it’s been a couple of months since my last post, but I already have something new to share with you.

It is related to API3:2023 Broken Object Property Level Authorization and privilege escalation.

This vulnerability belongs to the OWASP API Security Top 10.

But first, what does the OWASP documentation tell us about it?

When allowing a user to access an object using an API endpoint, it is important to validate that the user has access to the specific object properties they are trying to access.

An API endpoint is vulnerable if:

• The API endpoint exposes properties of an object that are considered sensitive and should not be read by the user. (previously named: “Excessive Data Exposure”)
• The API endpoint allows a user to change, add/or delete the value of a sensitive object’s property which the user should not be able to access (previously named: “Mass Assignment”)

Understanding this, let’s move on to vulnerability.

During this test, I was assigned a user with basic permissions within the platform. As we can see in the image, I only have permission to view reports, orders and appointments.

when inspecting the website, look at several endpoints including the following https://{redacted}/general-api/v1.0/teamMember, this endpoint shows us the user’s configuration in a json..Which showed the following information when review with Firefox Devtool

object  {3}
 user  {15}
    isActive : true
    jobTitle : ServiceAdvisor
    jobTitleOther : null
    dmsIDNumber : null
    landlinePhoneNumber : 6666666
    landlinePhoneExtension : 
    mobilePhoneNumber : 
   permission  {11}
        shouldReceiveUploadNotifications : false
        allowEditEstimates : false
        settingsAccess : false
        allowShowEstimates : false
        allowGenerateReports : true
        allowSeeAppointments : true
        allowEditAppointments : true
        allowSeeAllOrders : true
        allowEditOrders : true
        allowSeeAllConversations : false
        allowEditWorkshopPlanner : false
 userSchedule  [7]

Reviewing the response, I was able to see the following objects. As we can see the object permissions only accepts booleans.

permission  {11}
        shouldReceiveUploadNotifications : false
        allowEditEstimates : false
        settingsAccess : false
        allowShowEstimates : false
        allowGenerateReports : true
        allowSeeAppointments : true
        allowEditAppointments : true
        allowSeeAllOrders : true
        allowEditOrders : true
        allowSeeAllConversations : false
        allowEditWorkshopPlanner : false

By sending a POST request with the settingsAccess as true, it allows us to change the setting and access to configurations in the menu section, where we can create user and change our privileges. As we can see, it returns the result as 200 OK in Postman.

The API endpoint is vulnerable because there is no validation that the user should have access to the internal object property permissions.

in the following image we can see the user that was updated, with admin permissions in the dashboard.

What can we do to prevent this?

The OWASP documentation tells us the following:

When exposing an object using an API endpoint, always make sure that the user should have access to the object’s properties you expose.

Avoid using generic methods such as to_json() and to_string(). Instead, cherry-pick specific object properties you specifically want to return.

If possible, avoid using functions that automatically bind a client’s input into code variables, internal objects, or object properties (“Mass Assignment”).

Allow changes only to the object’s properties that should be updated by the client.

Implement a schema-based response validation mechanism as an extra layer of security. As part of this mechanism, define and enforce data returned by all API methods.

Keep returned data structures to the bare minimum, according to the business/functional requirements for the endpoint.

I hope you have learned something about this vulnerability, as I have. For more information about API vulnerabilities go to OWASP API Security Top 10