Session termination is an important part of the session lifecycle. Reducing to a minimum the lifetime of the session tokens decreases the likelihood of a successful session hijacking attack. This can be seen as a control against preventing other attacks like Cross Site Scripting and Cross Site Request Forgery. Such attacks have been known to rely on a user having an authenticated session present. Not having a secure session termination only increases the attack surface for any of the attacks, for example, account deletion without a password or bypassing the same.
A secure session termination requires at least the following components:
- After updating the Password or Email.
- Session termination after a given amount of time without activity (session timeout).
- Proper invalidation of server-side session state.
Lets talk about the ulnerability I found,
Consider a site “example.com” where users can signup and use the account, It also contains the dashboard where it has options like Update Email, Password, Delete Account etc.
I created an account using xyz@gmail.com and logged in with two different browsers. Later, I updated the email on one of the browsers and checked on the other browser to invalidate the session, but the server was not validating the session of the user. Other sessions remained active even after the password was changed, So I thought to check for he account deletion funtion.
Account deletion function here was asking the reason and later password for confirming the delete action by the user. So I sent the request to the Burp-suite and Intercepted the response for the same. The resposnse contained json syntax with
{
"success":true
}I quickly created another account, put in the wrong password, and captured the response, which was “success”:false as I expected. Now I changed the false -> true and am successfully able to delete the account without the actual password.
Senario:
Lets consider user A is going to login with a computer at Library or some public PC, then he forgots to logout. Later, User A is going to change the password, but the session will still be active on the PC where he logged in. Now consider an attacker who logs into User A’s account and then uses the account delete functionality to delete the account without knowing the actual password.
That wraps it up for now, I’ll be posting additional bugs that I found. Thanks for checking in!