OWASP’s number 6 in the API top 10 list, the Mass Assignment vulnerability, has become more common in the past few years. The exploitation of this vulnerability can lead to less critical consequences such as changing the price of a product to buy it at a cheaper price, and at the same time it could also lead to escalating privileges to access admin rights, which can cause huge damages to applications and companies. The impact of this vulnerability depends on how your application is built, which we will explore in this article.
What is the Mass Assignment vulnerability?
Mass assignment is a functionality provided to developers by most frameworks to enable easy mapping. Mass assignment refers to the practice of assigning values to multiple variables or object properties all at once, which simplifies the process of binding user-data into data objects. Even though this feature simplifies the development process, it also leads to security vulnerabilities.
Let’s explore the API Mass Assignment vulnerability with an example:
Say your organization is using an application with two user-roles – an admin user role and an editor user role. You have signed up as a part of your organization’s team as an editor. Based on your role’s permissions you shouldn’t be able to change your user role, as only the admin can make such changes. However, you can edit your name and email address from the profile settings. So, you access the profile settings, edit the first name and last name, and click save. Upon saving, a request is generated as follows:
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Firefox/102.0
Accept: application/json, text/plain, */*
Accept-Encoding: gzip, deflate
Authorization: Token eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJlbWFpbCI6ImhpbWFuc2NoQGdtYWlsLmNvbSIsInVzZXJuYW1lIjoiaGltYW5zY2giLCJpYXQiOjE2NTY5NDQ5MTYsImV4cCI6MTY2MjEyODkxNn0.06ARjpeBlVVJdYysQayH10LRNfM-EFIhlvBiroVHRjs
"first name": "Carol",
"last name": "Gibson"
To this request, you will get a 200 OK response and the changes are updated.
HTTP/1.1 200 OK
Date: Wed, 06 Jul 2022 07:18:26 GMT
Content-Type: application/json; charset=utf-8
alt-svc: h3=":443"; ma=86400, h3-29=":443"; ma=86400
"first name": "Carol", "last name": "Gibson", "isAdmin": "false"
In the response above we can see that there is an additional object property present: isAdmin. This object was not a part of the request, however a threat actor can see it because this object property is present in the response. So what if the threat actor submits a malicious request after learning about this object property?
"first name": "Carol",
"last name": "Gibson",
If your application uses mass assignment to automatically update the properties of the user object, then upon sending the above-mentioned request by the threat actor, it would update the isAdmin field of the object as well, and grant the attacker from the above example with admin privileges. This would lead to the malicious user escalating the privileges and accessing the application as admin. This is how a mass assignment vulnerability looks like.
In the same way, if there are more object properties exposed to the end user in the responses,a threat actor can use those object properties in the malicious requests to gain additional privileges or access privileged information which the user does not have access to.
This vulnerability has a varying impact depending on what critical functions the exposed object properties carry. A threat actor can learn about these exposed object properties either through the API responses, publicly disclosed API documentation, or simply by guessing the object properties.
The possible impact of the Mass Assignment Vulnerability
Threat actors can exploit mass assignment vulnerabilities to manipulate the internal state of the application, which can lead to a potential compromise of the confidentiality, integrity of the user data and availability of the application. Simply by using certain exposed object properties, an attacker may be able to escalate privileges and gain access to admin rights, thus bypassing the authorization mechanism. Depending on the functionality of the application and the level of authorization, this could lead to irreversible damages.
There are a few real-world examples of this vulnerability. One of them is the GitHub security breach that happened in 2012. A security researcher found a mass assignment vulnerability that led him to gain access to repositories with super-user privileges. This security researcher was able to do so by exploiting the public key update functionality that was vulnerable to mass assignment vulnerability. This issue was later resolved with no loss of data.
Mass assignment is currently listed at number 6 in the OWASP top 10 API vulnerabilities. It doesn’t get as much stage time as the other vulnerabilities in the list, but we are seeing a rise in awareness of the impact it poses to applications and businesses.
How to Protect against Mass Assignment Vulnerability?
There are a few basic actions developers can take to prevent this vulnerability from affecting their APIs:
- Avoid using functions that automatically bind incoming data and internal objects.
- Use an allow-list to only allow assignment on specific object properties or variables.
- Verify that frameworks which are in active use, protect against mass assignment attacks, or that the application has predefined countermeasures to protect against malicious parameter assignment.
Mass assignment is a less discussed security threat even though it is in the OWASP API top 10, but it definitely poses a great danger to the confidentiality, integrity and availability of an application. To prevent mass assignment exploits from happening, we have to be sure to investigate all the properties the objects have on each API endpoint and we have to ensure that we do not expose the unused object properties in the responses. Even if a threat actor uses an object property in the malicious request by guessing, we have to process the request through an allow-list to only allow assignment on specific object properties.