Mass Assignment
Last updated
Last updated
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
A common example is when an attacker adds parameters to a user registration request, such as setting isadmin: true, to escalate their account privileges.
Explore API Documentation: Check the documentation for parameters related to user roles, permissions, and critical functionalities. Adding these parameters to requests might reveal vulnerabilities.
Observe Naming Conventions: Use the API as designed to understand parameter naming conventions, as this insight can guide potential parameters for attacks on other endpoints.
Fuzz for Blind Attacks: If there is no documentation, fuzz parameters by capturing requests and brute-forcing values. Starting with account registration is a good approach, as it often contains exploitable user input.
Let's intercept the account registration request for crAPI.
Create a New Account: Use the application to register a new account while intercepting the request.
Submit the form to create an account and make sure the request was intercepted with Burp Suite.
Send the Intercepted Request to Repeater: Once intercepted, send the request to Burp Suite's Repeater to modify and test different payloads.
Modify JSON Payload: Alter the JSON payload by adding parameters like "isadmin": true, "admin": 1, or similar variations. Send each modified request and observe the API's responses for unique indicators of privilege escalation or success.
Analyze API Responses: If the API responds with no changes or indications of status alteration, the target may not be vulnerable. However, if variations in response occur, it suggests potential vulnerability.
Use Intruder for Variants: If you want to explore combinations of parameters systematically, send the request to Burp Suite's Intruder, set payload positions around the admin-related parameters, and run a “Cluster Bomb” attack.
Install Param Miner: Ensure you have the Param Miner extension in Burp Suite.
Right-click on a request to mine parameters using Param Miner.
Configure Param Miner options and click OK.
Review Detected Parameters: After running, check the Output tab for any new parameters that can be tested.
Reinsert Parameters for Fuzzing: Insert these parameters back into the original request to see if they trigger any responses that could indicate a vulnerability.
Unauthorized Access to Organizations: If the application allows users to be part of organizational groups, you can test for unauthorized access to those groups. This can often be done by modifying request parameters to include organizational identifiers.
Example: By adding an "org" parameter to a request and experimenting with different values, you might be able to access groups that a user is not supposed to see or interact with. This is particularly relevant in applications that manage organizational hierarchies or user groups.
Access Control Over Object Properties: Beyond organizational access, look for other sensitive properties within user objects that should be protected. This can include user roles, permissions, or configuration flags.
Testing Method: If you find an endpoint that modifies user settings, try adding parameters related to roles or permissions (like role, permissions, or access_level).
Modification of Related Objects: Identify relationships between objects in the API. For instance, if a user can modify their profile, check if that request can also include changes to associated objects, such as linked accounts, payment methods, or preferences.
Hunting for Mass Assignment
Analyze the Target API Collection:
Review the API documentation or captured traffic to identify endpoints that:
Accept user input.
Allow modification of objects.
Create a New Collection for Testing:
Set up a separate collection specifically for mass assignment testing to prevent unintentional modifications to the original API collection.
Duplicate Requests: Take interesting or relevant requests and duplicate them in your new collection.
Understand Each Request's Purpose:
Understand the functionality of each request in the API collection.
Test Various Endpoints:
Explore endpoints used for updating accounts, group information, user profiles, company profiles, etc.
Modify requests to test for potential mass assignment vulnerabilities by adding unexpected parameters.
Analyze API Responses:
Observe the API’s responses to modified requests to determine if any indicate privilege escalation or unauthorized access.
