API6:2019 Mass Assignment

Introduction

API6:2019 Excessive Data Exposure

Threat agents/attack vectors	Security weakness	Impacts
To thoroughly understand this issue we need to have great overview of the logic and the objects that are used, so notes are very important here. If you see any object, note it down. The same goes for making notes about the applications' logic. Pay close attention to the properties of the object when noting them down as well.	Applications these days try to focus heavily on using frameworks which will automatically link the front end objects into variables. While this does cut down on development time, attackers can often use these frameworks to their advantage by updating bound variables they should not be able to edit such as "isAdmin: false > isAdmin:true"	The impact really depends on what property of what object you were able to edit. For example if i can make myself admin by changing the isAdmin property of my own user object would be worse than if I could edit the stock of a product, even though that is also bad. As you can see, this vulnerability has a big range when it comes to impact.

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:

Account.AccountType or Account.discountsEnable. These are properties that relate to permissions

Account.wallet This property should never be editable be the attacker

product.title These are internal properties the user should never 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.

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

Response from API:

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

A second subtilty that comes into play is that we need know that it's a pretty bad thing to change account types but looking at the website (which was not in scope but it's a public asset, www.FAKEPAGE.com ) on that page we found that one account type costs a lot more than the other thus increasing the impact.

Preventive Measures Against Mass Assignment

You should try to disable the automatic mapping of properties whenever possible, all properties should be mapped manually and others should be ignored.

You should not rely on a blacklist to block the data that the user is not allowed to edit but instead you should rely on a whitelist that enables users to edit specific objects. This will be more resource intensive though as you have to have a really good overview of the logic and properties of the application but knowing this brings a lot more security to the table is a strong argument for the added cost.

Rely on the functions of the framework when blacklisting or whitelisting instead of writing your own. These functions have been tested many times over so they are more likely to be safe than a custom built solution.

If you have the resources, you should investigate the request and responses that reach the API and what properties they can have. Test if parameters the user can not edit are actually read only by sending them in a request and trying to edit them.

Conclusion

As you can see you need to think very carefully about the function of every parameter and make sure you understand what it means and what all the options are with that specific property. Make sure you investigate all the properties the objects have on the API and that unused properties do not get sent to production where they might get abused.