From a7ee52021367b6c7b25bcda21c884334b3c3e3db Mon Sep 17 00:00:00 2001 From: Ryan Rudder <96507400+RRudder@users.noreply.github.com> Date: Fri, 20 Oct 2023 14:36:57 +1000 Subject: [PATCH] Addition of Failure to Invalidate Session on Permission Change Added to address VRT PR 365 - https://github.com/bugcrowd/vulnerability-rating-taxonomy/pull/365 --- .../on_permission_change/guidance.md | 7 +++++++ .../on_permission_change/recommendations.md | 9 +++++++++ .../on_permission_change/template.md | 20 +++++++++++++++++++ 3 files changed, 36 insertions(+) create mode 100644 submissions/description/broken_authentication_and_session_management/failure_to_invalidate_session/on_permission_change/guidance.md create mode 100644 submissions/description/broken_authentication_and_session_management/failure_to_invalidate_session/on_permission_change/recommendations.md create mode 100644 submissions/description/broken_authentication_and_session_management/failure_to_invalidate_session/on_permission_change/template.md diff --git a/submissions/description/broken_authentication_and_session_management/failure_to_invalidate_session/on_permission_change/guidance.md b/submissions/description/broken_authentication_and_session_management/failure_to_invalidate_session/on_permission_change/guidance.md new file mode 100644 index 00000000..77f78e98 --- /dev/null +++ b/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). diff --git a/submissions/description/broken_authentication_and_session_management/failure_to_invalidate_session/on_permission_change/recommendations.md b/submissions/description/broken_authentication_and_session_management/failure_to_invalidate_session/on_permission_change/recommendations.md new file mode 100644 index 00000000..c84810e4 --- /dev/null +++ b/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: + +- diff --git a/submissions/description/broken_authentication_and_session_management/failure_to_invalidate_session/on_permission_change/template.md b/submissions/description/broken_authentication_and_session_management/failure_to_invalidate_session/on_permission_change/template.md new file mode 100644 index 00000000..6ba5b897 --- /dev/null +++ b/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}}