Addition of Failure to Invalidate Session on Permission Change

submissions/description/broken_authentication_and_session_management/failure_to_invalidate_session/on_permission_change/guidance.md

@@ -0,0 +1,7 @@
+# Guidance
+
+Provide a step-by-step walkthrough with a screenshot on how you exploited the vulnerability. Your submission must include evidence of the vulnerability and not be theoretical in nature.
+
+Please include screenshots showing the permission change process not removing a token from the cache and performing a sensitive action.
+
+Attempt to escalate the vulnerability to perform additional actions. If this is possible, provide a full Proof of Concept (PoC).

submissions/description/broken_authentication_and_session_management/failure_to_invalidate_session/on_permission_change/recommendations.md

@@ -0,0 +1,9 @@
+# Recommendation(s)
+
+It is best practice to invalidate all of a user's sessions upon changing the permission level and have the user login to their account again.
+
+Additionally, consider implementing a robust permission management system for control and tracking of user permissions and account access.
+
+For further information, please see Open Web Application Security Project (OWASP) guide relating to this:
+
+- <https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html#renew-the-session-id-after-any-privilege-level-change>

submissions/description/broken_authentication_and_session_management/failure_to_invalidate_session/on_permission_change/template.md

@@ -0,0 +1,20 @@
+# Failure to Invalidate Session on Permission Change
+
+Failure to invalidate a session after permission change is a vulnerability which allows an attacker to maintain access on a service. An attacker can use previously acquired sessions to continue accessing an account upon permission level change, including the revoking of permissions. This allows an attacker to gather information about an application’s endpoints an unauthenticated user will not usually have access to. The attacker's actions are limited by the privileges of the user account that they have access to. This could include viewing or editing sensitive customer data, or, viewing or editing other user permissions.
+
+## Business Impact
+
+This vulnerability can lead to reputational damage and indirect financial loss to the company as customers may view the application as insecure.
+
+## Steps to Reproduce
+
+1. Using one browser (Browser A), sign into a user's account using the login page: {{URL}}
+1. Using a different browser (Browser B), sign into the same user's account
+1. Using Browser A, change the permission level of the account
+1. Using Browser B, observe that the user session is still valid with elevated account permissions
+
+## Proof of Concept (PoC)
+
+The following screenshot(s) demonstrate(s) this vulnerability:
+
+{{screenshot}}