Skip to main content

Mass Assignment Strategy

The "mass assignment" vulnerability is one of the peculiar vulnerabilities of this application domain. This vulnerability originates from a misconfiguration of any REST API framework that can provide an automatic binding between input data fields (controlled by a potential attacker) and the internal data representation (e.g. database columns). Successful exploitation of such a vulnerability may allow malicious attackers to manipulate private data. However, they would have to guess the names of the internal data structures (e.g. database tables and columns) used by the REST API.

RTG provides a strategy for trying to detect this flaw within the REST API to be tested. In this case, the latter's specification is analysed to see which data should not be overwritten by incoming requests. These are the read-only data that are supposed to be good candidates for the mass assignment attack. Next, concrete test scenarios are generated by instantiating them from a catalogue of abstract test patterns. Finally, a security oracle monitors the execution of these test cases to reveal when a vulnerability is exposed.

The OWASP Foundation provides some guidelines for detecting and mitigating mass assignment vulnerabilities even if the source code is not available, as in the case of black box testing. The guidelines must be implemented manually by developers as there is no suggestion on how to make this procedure automatic.In RTG, therefore, a security testing approach is proposed to automatically find potential vulnerabilities of this type in REST APIs.
The proposed strategy for testing the vulnerability of mass assignment consists of three main steps:

  • Identification of read-only attributes: the OpenAPI specification is analysed, and operations and their input and output parameters are identified. Operations are subject to clustering, i.e. they are grouped according to the resources they handle. Then, operations that handle similar resources are compared to identify those that handle read-only attributes (i.e. those that appear in read operations, but not in write operations). The semantics of the operations are inferred based on the HTTP method that is used. In particular, operations using the POST method are annotated with C (Create); operations using the GET method to read a single resource are annotated with R (Read), while they are annotated with RM (Read Multi) if they read multiple resources at a time; operations using PUT and PATCH, on the other hand, are annotated with U (Update); finally, operations using the DELETE method are annotated with D (Delete). As mentioned above, operations with the most similar parameters are clustered. To do this, the EM (Expectation Maximisation) algorithm is used. First, input and output parameter names are collected for all operations in the specification. The names are normalized according to Porter's stemming algorithm, duplicate names are discarded, and the remaining ones are sorted alphabetically. When the clustering algorithm is applied, the optimal number of clusters is automatically defined, and which operations belong to each cluster based on the parameters in common.
  • Test case generation: test scenarios are automatically generated as sequences of requests with the purpose of overwriting read-only attributes.
  • Security Oracle: test cases are executed on the REST API and their execution is monitored by this oracle (security oracle). The oracle reveals that a mass assignment vulnerability has been correctly exposed when a test case manages to overwrite a read-only attribute. To this purpose, the oracle verifies that the same resource-id is used by all operations in a sequence and that the injection was successful with a value other than the default.