Parameter-based BAC & IDOR

In the context of IDOR testing, the security of the target relies entirely upon the quality of the implementation of the CRUD functionality. In my experience, the standard CRUD functionality can be categorized as follows:

  1. Users: Personal settings, owned resources, interactions, memberships.
  2. Spaces: Space settings, space participants, resources in the ownership of the space (which may be subordinate spaces).

At present, BAC vulnerabilities such as "passing an intended accessor ID to the controller" or "altering the value of the isAdmin parameter for access to the administrator panel," while they do occur, are less common. Nonetheless, as is often the case with scalability, problems arise.

In general, within the context of spaces, the rights of service clients can be classified into 7 user levels:

  1. Administrator
  2. Moderator
  3. Owner Participant (creator of subordinate ownership within a space)
  4. Participant
  5. Participant with reduced privileges
  6. User (a user with no access to the space)
  7. Unauthorized User

The functionality of each subcategory is determined by a pool of API endpoints responsible for specific actions on the target resource and depends on category settings. All of this can be be usefull in delineating CRUD functionality according to access levels, as it is crucial to test each endpoint separately using the authorizations of each user level with access restrictions to that endpoint.

The functionality of Create, Update, and Delete for user categories is almost always protected against IDOR checks by the server-side verification of provided user's access wrt an endpoint in question. Bypassing these restrictions falls outside the scope of IDOR testing. Usually when, passing some unknown parameters as part of the request one has to check if these are mandatory, it's source and it's calculation algoritm. When passing parameters that are responsible for access level checks one has to check it's validation on the server-side.

Consider a hypothetical scenario: Imagine a forum with a certain community, where a community moderator posts a private message accessible only to moderators. In this case, considering the classification above, the community can be classified as a "space," and the post as a subordinate space, since it contains distinct settings. Upon publication, the post is assigned an Id value of 123, following the previous publicly accessible post with Id 122. This allows users of the participant level to easily determine Ids of private posts. When accessing the resource directly (vulnapp.com/group_3/p123), the server correctly verifies the authentication measures. However, when accessing the REST API endpoint changeViewPermissions, responsible for altering the list of user levels with access to the post, the server incorrectly verifies the values of the Authorization and Cookie headers, instead relying on the parameters username and secret_value. What secret_value is remains unknown to the attacker, but by making a similar request in their own community and tracking the source of the value, they notice that it is obtained in response to a certain API call by passing their own userid value in the request. The attacker, upon entering the list of moderators in the target community and obtaining the desired userid, decides to make a similar API request to obtain the "secret_value" but this time by passing the moderator's userid value, and having received the requested value in the response, proceeds to make a request to change the visibility settings of the target private post, resulting in a positive outcome.

POST /group_3/p123/changeViewPermissions
Host: vulnapp.com
Authorization: Bearer ***
Cookie: ***

{"userid": "6343", "secret_value": "***"}