Broken Object Property Level Authorization

Broken Object Property Level Authorization refers to a category of vulnerabilities that includes two main subclasses: Excessive Data Exposure and Mass Assignment.

An API endpoint is considered vulnerable to Excessive Data Exposure if it inadvertently discloses sensitive data to authorized users that they are not meant to access.

Conversely, an API endpoint is vulnerable to Mass Assignment when it allows authorized users to manipulate sensitive object properties beyond their permitted scope. This includes the ability to modify, add, or delete values.

Exposure of Sensitive Information Due to Incompatible Policies

The first endpoint we will be checking against is vulnerable to CWE-213, Exposure of Sensitive Information Due to Incompatible Policies.

Scenario:

Assume received the credentials for the customers to assess the API endpoints vulnerabilities.

POC

1. Authenticate user and collect the JWT token for auth.

2. Check the current user roles

3. It is typical for e-commerce marketplaces to allow customers to view supplier details. However, after invoking the /api/v1/suppliers GET endpoint, we notice that the response includes not only the id, companyID, and name fields but also the email and phoneNumber fields of the suppliers.

These sensitive fields should not be exposed to customers, as this allows them to circumvent the marketplace entirely and contact suppliers directly to purchase goods (at a discounted price). Additionally, this vulnerability benefits suppliers financially by enabling them to generate greater revenues without paying the marketplace fee. However, for the stakeholders.

Prevention

To mitigate the Excessive Data Exposure vulnerability, the /api/v1/suppliers endpoint should only return fields necessary from the customers' perspective. This can be achieved by returning a specific response Data Transfer Object (DTO) that includes only the fields intended for customer visibility, rather than exposing the entire domain model used for database interaction.

Improperly Controlled Modification of Dynamically-Determined Object Attributes

The second API endpoint we will be checking against is vulnerable to CWE-915, Improperly Controlled Modification of Dynamically-Determined Object Attributes.

Another Scenario:

1. After invoking /api/v1/authentication/suppliers/sign-in to sign in as a Supplier and obtain a JWT, the /api/v1/roles/current-user endpoint shows that we have the roles SupplierCompanies_Update and SupplierCompanies_Get

2. When expanding the /api/v1/supplier-companies PATCH endpoint, we notice that it requires the SupplierCompanies_Update role, states that the supplier performing the update must be a staff member, and allows sending a value for the isExemptedFromMarketplaceFee field.

Then, when checking our company info again using /api/v1/supplier-companies/current-user, we will notice that the isExemptedFromMarketplaceFee field has become 1

To mitigate the Mass Assignment vulnerability, the /api/v1/supplier-companies PATCH endpoint should restrict invokers from updating sensitive fields. Similar to addressing Excessive Data Exposure, this can be achieved by implementing a dedicated request DTO that includes only the fields intended for suppliers to modify.

Thanks for Reading.