The binding client-provided data (e.g., JSON) to data models, without proper properties filtering based on a whitelist, usually leads to Mass Assignment. Either guessing objects properties, exploring other API endpoints, reading the documentation, or providing additional object properties in request payloads, allows attackers to modify object properties they are not supposed to.
- OWASP API Security Top 10 2019 Report
APIs contain information that only certain groups should be able to create, edit, update, or delete. Consider the outstanding customer debt in the case of a utility provider, for example – a payment system should be able to update this amount based on payments made by the customer, but the customer should not be able to directly edit this value. Mass assignment may make this value editable or deletable by the customer, which presents some potential for unwanted API behavior (since the utility company would not want their customers to decide how much they owe the company!). This issue is present at the API endpoint level.
The impact of these vulnerabilities can range in severity, from simple mistakes where a user may be able to post a thread in a non-existent forum, to account takeover or privilege escalation. For instance, as an unprivileged user, it is possible to use the profile updating page to elevate the privileges of the unprivileged user up to the administrator level (as explained by Gal Nagli). To do so, using a traffic content monitor to examine the JSON sent and received from the API, a user can check the difference between the JSON files sent as part of updating a user profile. For a regular and unprivileged user, the JSON sent to the API on profile update includes name, e-mail, and preferred language. With astute observation and key/value pair determination, sending in a JSON object containing the "roles":["administrator"] key/value pair allowed the previously unprivileged user to escalate their privileges to the administrator level.
Mass assignment endpoint vulnerabilities are found through reconnaissance. APIs that exhibit this behavior typically are built on frameworks; therefore, as part of reconnaissance, attackers often look for frameworks that may introduce this vulnerability by default. Another clue may be, for instance, when a user tries to change their password via an API, and the email field is automatically populated with the user’s email. These vulnerabilities are often born from a desire to make code reusable and abstract; however, this approach also inadvertently allows attackers to take advantage of these design decisions.
Whenever creating more flexible APIs, consider whether or not the client also requires this flexibility, or if some parameters are for internal use only.