API6:2019 Mass Assignment
Fast pace development environments or unclear business or functional requirements make developers choose generic implementations: binding client-provided data (e.g. JSON objects) to data models (e.g. those provided by popular ORM/ODM libraries) is, unfortunately, a common pattern that leaves the door wide open to all sorts of abuse.
What is the issue?
Client-provided data (e.g. JSON) is bound to data models, such as those provided by popular ORM/ODM libraries, without filtering what properties are meant to be directly set by the user/client. This may lead to all sorts of issues such as privilege escalation, unlock premium features, etc.
How does it look like?
An authenticated request to the /profile endpoint returns the JSON object on the right:
Due to the predictable nature of REST APIs, it is expectable that issuing a PUT request to the same endpoint with the previously returned JSON object in the request body, will update the user profile.
Note that in the request body plan property value was changed from “FREE” to “PRO” (highlighted on the left). The server returned a 204 No Content success status response code indicating that the request has succeeded. Repeating the initial request, now the server returns the updated profile.
In this example, it is reasonable to assume that “plan” property was not supposed to be directly updatable by the profile owner but, instead, by some internal mechanism, as a consequence of a successful plan upgrade that may require payment.
Sometimes attackers don’t know what other properties belong to a specific resource. They can either use any available documentation, data returned by other endpoints, guess or fuzz common property names until they experience some behavioral change e.g. unlock some PRO features.
Where have we seen this issue lately?
A vulnerability was found in EVBox, a smart electric vehicle charging station, leading to privilege escalation. The same happened to Harbor, a cloud native registry: adding the has_admin_role property in the signup request payload and setting it to true would make the new user administrator.
Conclusion
Mass Assignment poses a serious risk to APIs leading to privilege escalation, data tampering, bypass of security mechanisms, and more. Exploiting Mass Assignment issues is not always an easy task, but attackers may take advantage of API3:2019 Excessive Data Exposure issues to gather knowledge about other API resource properties and their expected values (e.g. roles) or just fuzz property names/values based on wordlists.
Automatically binding client's input into data models should be avoided: schemas may prove themselves useful to restrict what properties should be returned to the client as well as those clients are allowed to manipulate.