OWASP API #6: Mass Assignment
This section
As a reminder, we started with this section a more than month ago. Our main purpose, is to share once a week, one of the top cybersecurity attacks that applications are suffering nowadays and help by explaining how you can prevent them from happening.
In each story, we go through ‘Brief explanation’, ‘Is my API vulnerable?’, ‘Attack scenarios’ and ‘How to prevent?’, so by the end you have a comprehensive understanding.
If you missed the previous articles, we encourage you to go have a look. We have already covered:
- Broken Object Level Authorization
- Broken Authentication
- Excessive Data Exposure
- Lack of Resources & Rate Limiting
- Broken Function Level Authorization
API #6: Mass Assignment
This week, we are going to talk about ‘Mass Assignment’, which if not working with incoming data transfer objects or models, is often left unattended. This can cause several problems, as it allows an attacker to modify data that he should not be intended to.
Brief explanation
Mass Assignment, occurs when an application is implemented in such way, that it actually accepts broader modifications than those intended and described in the documentation.
Is my API vulnerable?
Objects in modern applications might contain many properties. Some of these properties should be updated directly by the client (e.g., user.first_name or user.address) and some of them should not (e.g., user.is_vip flag).
If your API has an endpoint, that converts client provided parameters automatically into internal object properties without filtering, you are definitely exposed.
Example attack scenario
An application provides a user with the option to edit basic information for their profile. During this process, an API call is sent to PUT /api/v1/users/me with the following legitimate JSON object: {“user_name”:”santi”,”age”:24}
The GET /api/v1/users/me request includes an additional wallet_balance property: {“user_name”:”santi”,”age”:24,”wallet_balance”:1000}.
The attacker realizes that and replays the first HTTP request, but now he includes the new attribute, which results in the following payload:
{“user_name”:”attacker”,”age”:40,”wallet_balance”:99999}
Since the endpoint is vulnerable to mass assignment, the attacker receives credits without paying.
How to prevent?
- Avoid functions that automatically bind a client’s input into code variables or internal objects.
- Use DTO_IN and DTO_OUT to whitelists only the properties that should be updated by the client.
- Blacklist properties that should not be accessed by clients.
- If applicable, explicitly define and enforce schemas for the input data payloads.
Conclusion
In just a few lines, we have covered what Mass Assignment is and how much impact it can have in our applications. The good news, are that it is extremely easy to prevent and mitigate, as you only need to use Incoming Data Transfer Objects that states specifically which properties a function should map from the client’s provided payload.
Thank you for taking the time and reading this week’s story on OWASP API TOP 10. As usual, if you have any doubts or need any help, anyone at Strike will be happy to help you. You can reach out to me here or in LinkedIn!
If you want to see daily news, tips and funny memes (yes, we are into that too :D), be sure to give us a follow there too.
Cheers from Strike :)
