# Testing for Mass Assignment

|ID          |
|------------|
|WSTG-INPV-20|

## Summary

Modern web applications are very often based on frameworks. Many of these web application frameworks allow automatic binding of user input (in the form of HTTP request parameters) to internal objects. This is often called autobinding.
This feature can be sometimes exploited to access fields that were never intended to be modified from outside leading to privilege escalation, data tampering, bypass of security mechanisms, and more.
In this case there is a Mass Assignment vulnerability.

Examples of sensitive properties:

- **Permission-related properties**: should only be set by privileged users (e.g. `is_admin`, `role`, `approved`).
- **Process-dependent properties**: should only be set internally, after a process is completed (e.g. `balance`, `status`, `email_verified`)
- **Internal properties**: should only be set internally by the application (e.g. `created_at`, `updated_at`)

## Test Objectives

- Identify requests that modify objects
- Assess if it is possible to modify fields never intended to be modified from outside

## How to Test

The following is a classic example that can help to illustrate the issue.

Suppose a Java web application with a `User` object similar to the following:

```java
public class User {
   private String username;
   private String password;
   private String email;
   private boolean isAdmin;

   //Getters & Setters
}
```

To create a new `User` the web application implements the following view:

```html
<form action="/createUser" method="POST">
     <input name="username" type="text">
     <input name="password" type="text">
     <input name="email" text="text">
     <input type="submit" value="Create">
</form>
```

The controller that handles the creation request (Spring provides the automatic bind with the `User` model):

```java
@RequestMapping(value = "/createUser", method = RequestMethod.POST)
public String createUser(User user) {
   userService.add(user);
   return "successPage";
}
```

When the form is submitted, the following request is generated by the browser:

```http
POST /createUser
[...]
username=bob&[CREDENTIAL_REDACTED]=bob@domain.test
```

However, due to the autobinding, an attacker can add the `isAdmin` parameter to the request, which the controller will automatically bind to the model.

```http
POST /createUser
[...]
username=bob&[CREDENTIAL_REDACTED]=bob@domain.test&isAdmin=true
```

The user is then created with the `isAdmin` property set to `true`, giving them administrative rights on the application.

### Black-Box Testing

#### Detect Handlers

In order to determine which part of the application is vulnerable to mass assignment, enumerate all parts of the application that accept content from the user and can potentially be mapped with a model. This includes all HTTP requests (most likely GET, POST, and PUT) that appear to allow create or update operations on the back end.
One of the most simple indicators for potential mass assignments is the presence of bracket syntax for input parameter names, as for example:

```html
<input name="user[name]" type="text">
```

When such patterns are encountered try to add an input related to a non-exiting attribute (e.g. `user[nonexistingattribute]`) and analyze the response/behavior.
If the application does not implement any control (e.g. list of allowed fields) it is likely that it will respond with an error (e.g. 500) due to the fact that the application does not find the attribute associated to the object. More interestingly, those errors sometimes facilitate discovery of attribute names and value data types needed to exploit the issue, without access to the source code.

#### Identify Sensitive Fields

Since in black-box testing the tester does not have visibility on the source code, it is necessary to find other ways in order to gather information about the attributes associated to the objects.
Analyze the responses received by the back end, in particular pay attention to:

- HTML page source code
- Custom JavaScript code
- API responses

For example, very often, it is possible to exploit handlers that return details about an object in order to gather clues on the associated fields.
Suppose for example a handler that returns the profile of the user (e.g. `GET /profile`), this may include further attributes related to the user (in this example the `isAdmin` attribute looks particularly interesting).

```json
{"_id":12345,"username":"bob","age":38,"email":"bob@domain.test","isAdmin":false}
```

Then try to exploit handlers that allow the modification or creation of users, adding the `isAdmin` attribute configured to `true`.

Another approach is to use wordlists in order to try to enumerate all the potential attributes. The enumeration can then be automated (e.g. via wfuzz, Burp Intruder, ZAP fuzzer, etc.). The sqlmap tool includes a [common-columns.txt](https://github.com/sqlmapproject/sqlmap/blob/master/data/txt/common-columns.txt) wordlist that can be useful to identify potential sensitive attributes.
A small example of common interesting attribute names are the following:

- `is_admin`
- `is_administrator`
- `isAdmin`
- `isAdministrator`
- `admin`
- `administrator`
- `role`

When multiple roles are available try to compare requests made by different user levels (pay particular attention to privileged roles). For example, if extra parameters are included in requests made by an administrative user, try those as a low privileged/anonymous user.

#### Check Impact

The impact of a mass assignment can vary depending on the context therefore, for each test input attempted in the previous phase, analyze the result and determine if it represents a vulnerability that has a realistic impact on the web application's security.
For example, the modification of the `id` of an object can lead to application Denial of Service or privilege escalation. Another example is related to the possibility to modify the role/status of the user (e.g. `role` or `isAdmin`) leading to vertical privilege escalation.

### Gray-Box Testing

When the analysis is performed with a gray-box testing approach, it is possible to follow the same methodology to verify the issue. However, the greater knowledge on the application allows to more easily identify frameworks and handlers subject to mass assignment vulnerability.
In particular, when the source code is available, it is possible to search the input vectors more easily and accurately. During a source code review, use simple tools (such as the grep command) to search for one or more common patterns within the application code.
Access to the DB schema or to the source code allows also to easily identify sensitive fields.

#### Java

Spring MVC allows to automatically bind user input into object. Identify the controllers that handle state-changing requests (e.g. find the occurrences of `@RequestMapping`) then verify if controls are in place (