Addition - Failure to Invalidate Session On Permission Change

[evildaemond]

Description

The Bugcrowd VRT does not currently have a class for Failure to Invalidate a users session on a Change of Permission, this class has been mentioned on occasion however has not clearly been defined within the VRT.

The concept of this vulnerability category is when a user has had their permissions updated, for example changing a user from an Administrator role to a User role, the application uses the session token as authorisation that the user should have access to that functionality. When this form of permission management is in place, the application can fail to invalidate the session token for the user on a change of permission, meaning they maintain access to this functionality.

In some situations, this may be acknowledged by the client as a security risk, and mitigated through other methods, such as session timeouts set to a set period (I.E 30 minutes), however, in a situation where a user has a long or indefinite session timeout, they can maintain persistence for a longer period of time, this would require being chained to the VRT variant Broken Authentication and Session Management > Failure to Invalidate Session > Long Timeout.

Reproduction Steps

Note: Requires 2 users;

• User A: Who has the ability to change the permissions of another user
• User B: Our testing user who will have their permissions changed

1. Login via User A into the application on a browser
2. Login via User B into the application on another browser
3. Using User B, Access a part of the application which they have been granted permission to (I.E. Invoices), and make an action which can be sent to a repeater tool
4. From User A, make an update to the permissions of User B, in this case we'll say they have revoked access to the Accounting role and updated it to User
5. From User B's session, verify that the session token has not been updated through the cookies by accessing the application normally
6. Finally, from User B's session, repeat your request from Step 3, and verify that the action did complete

Recommendation

Based on the information outlined, I recommend an addition to the VRT inside of the category Broken Authentication and Session Management, under the vulnerability name Failure to Invalidate Session, which would encompass this variant On Permission Change.

Broken Authentication and Session Management > Failure to Invalidate Session > On Permission Change

Based upon the information outlined previously in the Description, this should be rated as a P5, while there is a vulnerability risk associated with this type of issue, at this stage I believe the risk to be minimal as other mitigations, such as session timeouts, actively mitigate the time this exploit can take place for. I would like to hear others thoughts on this category and if they believe the severity should be higher

[TimmyBugcrowd]

Hey @evildaemond

I do agree with having a VRT entry for this, however, I'm not sure if P5 is appropriate. I know that the security impact is low in that particular case but think about situations where UserB has been granted higher permissions, e.g deleting a project or even deleting another user or something.

There are also cases where there are more than just those 2 different users. E.g

1. Admin User - Can delete users
2. High Privileged User - Can delete a project
3. Regular User - Can only view the project

The security impact is not the same when invalidating the session of user 2. and 3. Also, looking at it from the 1.'s perspective, you want the session to be invalidated right away when doing the changes.

So, in my opinion, I would consider adding this category:

Broken Authentication and Session Management > Failure to Invalidate Session > On Permission Change - Varies

Let me know what you think.

[evildaemond]

No issues on my part.

[TimmyBugcrowd]

Closing this issue since a PR #365 for this has been submitted.