Introduction

API6:2019 Excessive Data Exposure

What is Mass Assignment?

Applications these days often rely an objects (For example user, product, ...) and these objects have properties (for example product.stock). As a user, we have the authorization to edit and view specific properties of the objects but we might also be limited and not able to edit or view some specific properties (For example user can view product.stock but user should not be able to edit product.stock). These properties are then matched to parameters on the front-end and if these conversions happen automatically, they might convert parameters to properties the attacker should not be able to access (For example, the user should never be able to edit product.title but the front-end might convert a parameter "title" to product.title if the user sends a PUT request).

Here are some more examples of properties the user should not be able to edit:

Example Attack Scenarios

These attack scenarios come from my personal experience as a bug bounty hunter. This happens to be my favourite issue type because it's really easy to miss them and you can not automate the search easily due to the required logic knowledge.

The first example is from an application that allows you to make an appointment which last 1 hour. In the UI I am able to see timeslots that last 1 hour and I can select one of them.

I was staring at the request and did not notice it at first, it took me a good hour to realise it:

{
"startDate":"29/04/2022 11:00",
"endDate":"29/04/2022 12:00",
"userID":"123",
"consultantID":"123"
}

If we change the start or end date we can fully book the agenda of the consultant for years if we wish. This is very easy to miss which is why I like this issue type so much!

{
"startDate":"29/04/2022 11:00",
"endDate":"29/04/2099 12:00",
"userID":"123",
"consultantID":"123"
}

A second example is that I love to look at my account settings when I am hacking to see if i can't find any properties in the api responses that I should not be able to edit to make myself admin for example but this is about a much more subtle bug.

Request:
{
"endDate":"29/04/2099 12:00",
"userID":"123",
"consultantID":"123"
}

Response from API:

{
"AccountType":"airport",
"endDate":"29/04/2099 12:00",
"userID":"123",
"consultantID":"123"
}

There are two account types in here, these account types can not be found in the requests themselves but only in the response however if I copy over that parameter, I might be able to change it as the API might automatically map the object.