Session Invalidation Testing with BurpSuite: Can You Still Modify an Account After Logout?

Logging out of a website should end your authenticated session and prevent further access to protected account features. Once a user logs out, the application should no longer accept requests that rely on the revoked session.

While testing a web application's account settings, I explored an interesting scenario involving profile modification after logout. I captured a name-change request using Burp Suite, sent it to Repeater, logged out of the application, and then replayed the same request.

Surprisingly, the server returned a successful response, and the account name appeared to change again. This observation raised an important security question: Does the application properly invalidate authenticated sessions when a user logs out?

In this article, I'll explain the testing process, the potential security implications, and how developers can prevent similar session-management issues.

Understanding Session Invalidation

Web applications commonly use session identifiers to recognize authenticated users across multiple requests. Depending on the application's architecture, these identifiers may be stored in cookies, such as PHPSESSID, and associated with server-side session data.

When a user logs out, the application should invalidate the corresponding session on the server. Simply redirecting the user to the login page or clearing a cookie in the browser is not necessarily sufficient if the server continues to accept the original session identifier.

If a previously authenticated request remains usable after logout, the application may have a session-management weakness. However, a successful response alone does not prove that the session is still valid; the actual account modification and server-side authentication behavior must also be verified.

Embedded content

Tools Used

For this test, I used the following tools and features:

• Burp Suite Proxy: To capture the profile modification request.
• Burp Suite Repeater: To replay the captured request and inspect the response.
• Web browser: To interact with the application, verify the account changes, and perform the logout action.

The test focused on an account I controlled. Testing should always be performed on systems you own or are explicitly authorized to assess.

Testing the Logout Behavior

Step 1: Create an Account and Log In

I started by registering a test account and logging in normally. After authentication, I navigated to the profile settings page, where the application allowed me to change the account name.

This established a baseline for the test. I confirmed that the profile modification feature worked as expected before investigating its behavior after logout.

Step 2: Capture the Name-Change Request

Next, I opened Burp Suite and captured the HTTP request generated when changing the account name. The request contained the relevant profile parameter and the session cookie used by the application.

I sent this request to Burp Suite Repeater so that I could resend it without repeating the entire browser workflow. I modified the name value and submitted the request, confirming that the application processed the change successfully.

Step 3: Log Out of the Application

After confirming the normal behavior, I returned to the browser and logged out using the application's logout functionality.

At this point, the expected behavior was that the authenticated session would be revoked. Any subsequent request relying exclusively on that invalidated session should no longer be authorized to modify the account.

Step 4: Replay the Captured Request

I returned to Burp Suite Repeater and resent the previously captured name-change request using the original session cookie.

The server returned a success response, which suggested that the request had been processed despite the logout action. I then checked the account state to determine whether the name had actually changed.

Step 5: Verify the Result

The account name appeared to change after logout. This was the key observation because it went beyond receiving a successful HTTP response and indicated that the requested modification had taken effect.

Based on this result, the behavior warrants further investigation as a potential session invalidation vulnerability. Additional testing is necessary to establish whether the server genuinely accepted a revoked session or whether another mechanism, such as a still-active session in another browser context, explains the result.

What Could Cause This Behavior?

Several implementation issues could explain the observed result. Identifying the actual cause requires examining how the application manages sessions and processes authenticated requests.

1. The server-side session is not invalidated

The logout handler may terminate the browser's local session state without revoking the corresponding session on the server. If the backend continues to recognize the old session identifier, previously captured requests may remain usable.

2. Logout clears only the browser cookie

Some applications clear the session cookie from the browser but leave the server-side session active. In that situation, the browser may appear logged out even though someone holding the original session identifier can still make authenticated requests.

3. The endpoint does not enforce authentication correctly

A profile modification endpoint should verify that the request belongs to a currently authenticated session. If the endpoint relies on insufficient checks or trusts stale authentication state, it may allow operations that should have been rejected.

4. The test environment retains another active session

The result could also be affected by multiple browser sessions, session renewal, or application-specific authentication behavior. These possibilities should be ruled out before attributing the finding specifically to improper session invalidation.

Security Impact

If the server accepts a revoked session after logout, the impact depends on the application's functionality and the privileges associated with that session.

An attacker who has obtained a valid session identifier may be able to continue performing authenticated actions after the legitimate user believes the session has ended. Depending on the application's design, those actions could include profile changes or other sensitive operations.

For this particular test, the demonstrated impact is the ability to change the account name after logout. Access to additional account functions, exposure of sensitive information, or account takeover should not be claimed unless separately demonstrated.

The risk may be greater on shared devices or in situations where a session token has been exposed. Proper logout handling is therefore an important part of protecting authenticated accounts.

How Should This Vulnerability Be Classified?

If further testing confirms that the server accepts a session that was successfully revoked during logout, the finding may be classified as an improper session invalidation issue.

Relevant references include:

• CWE-613: Insufficient Session Expiration — potentially relevant when a session remains usable beyond its intended lifetime.
• OWASP Top 10: A07:2021 — Identification and Authentication Failures — a relevant broader category for authentication and session-management weaknesses.

The final classification should match the verified root cause. A successful profile change after logout does not automatically establish a particular CWE or OWASP category.

Severity should also be based on the demonstrated impact, exploitability, and the application's context. A confirmed issue affecting only a low-risk profile field may warrant a different rating from one that enables continued access to sensitive account functions.

Recommended Remediation

Developers can reduce this risk by implementing robust server-side session management.

Invalidate sessions on logout. The logout endpoint should revoke the active session on the server, rather than relying exclusively on deleting the browser cookie.

Validate authentication on every protected request. Account modification endpoints should verify that the associated session is active and authorized before processing the request.

Reject revoked session identifiers. Once a session has been invalidated, replaying a request with its former identifier should not restore authenticated access.

Manage session expiration and rotation. Applications should enforce appropriate expiration rules and rotate session identifiers when required by the authentication lifecycle.

Test logout across sensitive endpoints. Security testing should verify that previously captured requests cannot perform protected actions after the associated session has been revoked.

Conclusion

This test demonstrated an interesting security behavior: a profile name-change request appeared to succeed even after I logged out of the application. By capturing the request in Burp Suite and replaying it through Repeater, I was able to investigate whether the application properly enforced session invalidation.

A secure logout process should do more than redirect a user to a login page. It should ensure that revoked sessions can no longer authorize protected operations.

AI assistance:_ I used an AI-powered grammar and spelling checker to review this article. The ideas, research, technical analysis, and final content are my own._

Have questions or want to share your own workflow? Drop a comment below or connect with me on :

🔗Linkdin: https://www.linkedin.com/company/sam-shield/

🔗Youtube: https://www.youtube.com/@sam_shield-w7l

🔗Medium: https://medium.com/@samadhanshimple