Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.
To thoroughly understand this issue we need to have a great overview of the logic that is used and the objects 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.
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 it 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.
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 conversion 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 favorite issue types because it's really 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 lasts 1 hour. In the UI I am able to see time slots 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 realize it:
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.
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.
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 blocklist 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.
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. And also don't forget about API protection. We've compiled the OWASP Top 10 in 2021 based on millions of safety reports, read this article.
20+ years IT expertise in system engineering, security analysis, solutions architecture. Proficient in OS (Windows, Linux, Unix), programming (C++, Python, HTML/CSS/JS, Bash), DB (MySQL, Oracle, MongoDB, PostgreSQL). Skilled in scripting (PowerShell, Python), DevOps (microservices, containers, CI/CD), web development (Node.js, React, Angular). Successful track record in managing IT systems.
Stepan is a cybersecurity expert proficient in Python, Java, and C++. With a deep understanding of security frameworks, technologies, and product management, they ensure robust information security programs. Their expertise extends to CI/CD, API, and application security, leveraging Machine Learning and Data Science for innovative solutions. Strategic acumen in sales and business development, coupled with compliance knowledge, shapes Wallarm's success in the dynamic cybersecurity landscape.