Mass Assignment is a vulnerability wherein an active record pattern is manipulated into modifying data items that should normally restrict user functions such as passwords, granted permissions, or admin access. They arise when objects on the backend e.g. database records, are created by using the object representation received with the client request including fields that are not intended to be freely altered.
Active record and object-relational mapping are common features in many web application frameworks as they allow for serialized external data to be automatically converted upon input into internal objects and, subsequently, into the database records field. Depending on the framework, developers are sometimes allowed to automatically bind HTTP request parameters into program code variables or objects for ease of use. However, if the conversion interface for the framework is overly permissive and developers haven’t marked specific fields as immutable, the potential for exploitation is open.
Malicious attackers can leverage Mass Assignment vulnerabilities to manipulate the internal state of the application and potentially compromise its confidentiality, integrity, and availability. By overwriting the value of certain fields, an attacker may be able to modify an admin permission flag, thus effecting an authorization bypass which, depending on the level of authorization, could lead to full server access.
In 2012, none other than Github, the world’s code repository, was shown to be harbouring a potentially catastrophic Mass Assignment vulnerability that ended up being exposed by a security researcher in a fairly public stoush. The issue was fortunately resolved with no loss of data; but the security researcher in question was able to upload his public key to any organisation and thus potentially make malicius changes in their repositories.
The following exemplifies a Mass Assignment attack within a web application that stores users in a NoSQL database and implements access control by simply keeping one boolean flag
is_admin for each user.
Upon sign up, some fields need to be used to create the new user. If the web application uses the whole POST data to build a new
User object, a malicious actor could add the
is_admin=1 field to the post data to overwrite the default value and gain administrative privileges on the application.
Developers must avoid using functions that bind client input into variables or internal objects automatically. Additionally, developers must explicitly define all payloads and parameters that the server is expecting.
Depending on the application framework, it may be possible to only allow fields that are determined safe to be fetched from the client request. If the application does not allow for this process, developers must ensure they manually determine which fields are allowed to be extracted from the request and used in downstream contexts.
Verify that frameworks protect against mass parameter assignment attacks, or that the application has countermeasures to protect against unsafe parameter assignment, such as marking fields private or similar.
- OWASP ASVS: 5.1.2
- OWASP Testing Guide: Test Business Logic Data Validation, Test Ability to Forge Requests, Test Integrity Checks