| Index | Section |
|---|---|
| 1 | About the attack |
| 2 | Scenario |
| 3 | How to test |
| 3.1 | Steps |
| 4 | What can be achieved |
| 5 | How to test |
| 6 | Practice |
| 7 | References |
Occurs when an app allows a user to manually add parameters in an HTTP Request & the app process value of these parameters when processing the HTTP Request & it affects the response that is returned to the user.
POST /userinfo
<redacted>
username=harsh
200 OK
<redacted>
username=harsh&isadmin=false&[email protected]
POST /userinfo
<redacted>
username=harsh&isadmin=true
200 OK
<redacted>
username=harsh&isadmin=true&[email protected]
Now consider the above example where an attacker observes normal request/response flow and notice there is a parameter called isadmin which is set to false.
The attacker tries to send "isadmin" with the value true in the HTTP request and as a result, in response, the "isadmin" parameter is now true and the normal user is now an admin user.
- This is a simple example of Mass Assignment Vulnerability.
Depending on the language/framework this issue has different names:
- Mass Assignment: Ruby on Rails, NodeJS.
- Auto binding: Spring MVC, ASP NET MVC.
- Object injection: PHP.
- Capture the Request and Observe its response.
- Include the parameters present in Response to the HTTP Request with the modified values.
- Observe if the values in response are changed as Modified values.
- Navigate to the application and observe if the changes are also reflected on the UI level.
- Authentication Bypass (2FA) - Adding "Success":true parameter in the request with the wrong OTP.
- Privilege Escalation - Changing the Role/Access Level.
- Modifying/Overwriting Sensitive Information.
- Client-Side/Server-Side validation might be missing in the parameters that are not editable by the user from the UI level and if can be abused through mass assignment, it can lead to exposure to some serious issues.
- Premium Feature Abuse/Bypass Payment Restrictions.