bWAPP, Logout Management (Session Invalidation Failure)

Author: Ratbully Platform: bWAPP (Broken Web Application) Lab/Module: Broken Auth, Logout Management Category: Broken Authentication / Session Management Levels Covered: Low, Medium, High

Objective

This report tests whether clicking "Logout" actually ends a session on the server, or only redirects the user back to the login page while leaving the underlying session token still valid. It also documents a second, related observation involving browser back button behavior after logout. Both findings sit under the same theme: a logout button that looks successful in the browser is not proof that the session was actually destroyed where it matters, on the server.

Methodology

• Dev Tools and manual session testing, capturing a live session token before logout, then attempting to reuse it afterward in a second, separate browser
• Source code review (via SSH), confirming exactly what each security level's logout handler does server side
• An initial test was run against the wrong page (the site's general logout button rather than this lab's own logout link) and corrected after reading the source, a good reminder to always confirm you are testing the exact mechanism a lab is built around

Plain Language Explanation

Think of logging out like handing back a hotel key card at the front desk. A properly run hotel deactivates that card the moment it is returned, so even if someone finds a copy of it later, it will not open your room anymore. A poorly run hotel might just take the card back and smile, without ever actually deactivating it in their system, meaning an old copy would still work. The question this lab answers is which kind of hotel each security level behaves like.

Attack 1: Session Hijacking After Logout

Low Security

What we did:

1. Logged in as bee in Browser A and copied the live PHPSESSID value
2. Clicked the lab's own logout link (not the site wide logout button)
3. In a separate, never logged in Browser B, manually set the PHPSESSID cookie to the value copied before logout
4. Loaded an authenticated page (portal.php) directly

What happened: Browser B was granted full authenticated access, even though the session had already been "logged out" in Browser A moments earlier.

Source code confirmation:

php

case "0" :
    // Do nothing
    break;

case "0" :
    // Do nothing
    break;

At Low, the logout handler does not destroy the session at all. It only clears a few unrelated cookies and redirects to the login page, the session token itself remains fully valid and reusable by anyone who obtained it beforehand.

Medium and High Security

What we did: Repeated the identical test at both levels.

What happened: The old session ID no longer worked at either level, Browser B was correctly denied access and redirected to login.

Source code confirmation:

php

case "1" :
    session_destroy();
    break;
case "2" :
    $_SESSION = array();
    session_destroy();
    break;

case "1" :
    session_destroy();
    break;
case "2" :
    $_SESSION = array();
    session_destroy();
    break;

Both Medium and High call session_destroy(), genuinely invalidating the session server side. High additionally clears the session array first, a slightly more defensive step, though both levels produced the same practical result in testing.

Attack 2: Back Button After Logout

What we observed: After logging out in Browser A, pressing the browser's back button returned to a page that still visually resembled the authenticated view, rather than immediately showing the login form.

Why this happens: This is a browser caching behavior rather than a server side session flaw, browsers often cache a page's rendered HTML and will display that cached copy when navigating back, regardless of whether the session backing it is still valid. This is a separate concern from the session hijacking finding above: the page shown via the back button is not necessarily still functional, interactive actions on that cached page (like submitting a form or loading new data) should still fail or redirect once attempted, since those require a fresh request that the server would reject.

Why it still matters: On a shared or public computer, a cached authenticated looking page being visible after logout can expose sensitive information at a glance, or create a false sense that the previous user is still logged in, even if deeper interaction would fail. Proper cache control headers (instructing the browser not to cache authenticated pages) are the standard fix for this class of issue.

Key Takeaways

• A logout button redirecting to the login page is not proof that the session was actually destroyed, the only real test is whether the old session token still grants access afterward.
• This flaw is a realistic, commonly seen issue, not just a lab artifact: any session token that leaked before logout (through browser history, a proxy log, or a borrowed device) remains a live threat if the server never truly invalidates it.
• The back button issue is a distinct, lower severity concern rooted in browser caching rather than session validity, but is still worth fixing on any page displaying sensitive information, since proper cache control headers prevent the browser from storing a visible copy at all.
• Testing against the correct page matters: an earlier attempt against the site's general logout button produced a misleading result, and was only caught by reading the actual source code behind this specific lab.

Tools Used

• Browser Dev Tools, capturing and manually setting session cookies across two separate browsers
• SSH and source code review, confirmed the exact logout logic (ba_logout_1.php) behind each security level