Authorization disclaimer. This walkthrough is limited to the intentionally vulnerable PortSwigger Web Security Academy lab linked below. Test only systems you own or are explicitly authorized to assess.

Overview

The server recognizes valid CSRF tokens but does not bind each token to the session that obtained it. Consequently, a fresh token taken from the attacker’s own account is accepted when the victim’s browser submits it alongside the victim’s authenticated session cookie.

Lab description explains that CSRF tokens are not integrated with session handling and provides separate wiener and carlos accounts.
Lab description explains that CSRF tokens are not integrated with session handling and provides separate wiener and carlos accounts.

Lab objective/setup

This intentionally vulnerable Academy exercise isolates csrf where token is not tied to user session. The supplied accounts and endpoints are used to reproduce only the source note evidence for csrf where token is not tied to user session; all request changes remain inside this Academy instance.

What I observed

The account page renders a csrf value for the currently logged-in attacker. The decisive observation is not merely that the token has valid syntax: replaying that attacker-issued token in a request authenticated as the victim is accepted. The application checks membership in a global pool of valid tokens rather than ownership by the current session.

My Account shows the email-change form in the attacker-controlled wiener session.
My Account shows the email-change form in the attacker-controlled wiener session.

Why it is vulnerable

Token validity is global rather than session-specific. Because the server never verifies that the submitted token was issued to the session cookie authorizing the request, the attacker’s token remains valid when paired with the victim’s login state.

Walkthrough in the authorized PortSwigger lab

  1. Sign in to the attacker-controlled account and open /my-account to obtain a fresh valid csrf value from the email-change form.
  2. Build an exploit-server form targeting POST /my-account/change-email, placing the attacker account’s token in the hidden csrf field and the required address in email.
  3. Deliver the auto-submitting form to the victim. Their browser sends the victim’s authenticated session cookie, while the form supplies the valid token obtained from the attacker’s separate session.
  4. Observe that the request succeeds. This cross-session acceptance is the exact weakness: token validity is checked, but the token is never associated with the user session authorizing the email change.
1
2
3
4
5
6
7
8
9
<html>
  <body>
    <form action="https://LAB/my-account/change-email" method="POST">
      <input type="hidden" name="email" value="[email protected]" />
      <input type="hidden" name="csrf" value="<ATTACKER_TOKEN>" />
    </form>
    <script>document.forms[0].submit();</script>
  </body>
</html>
The account-page HTML exposes the hidden csrf input and its attacker-session token value.
The account-page HTML exposes the hidden csrf input and its attacker-session token value.
The exploit-server editor contains an auto-submitting POST /my-account/change-email form with email=hacked@hacker.com and the csrf token taken from the attacker session.
The exploit-server editor contains an auto-submitting POST /my-account/change-email form with [email protected] and the csrf token taken from the attacker session.

Verification

The final capture shows the Academy marking the csrf where token is not tied to user session exercise as solved after the documented request sequence. No testing was performed outside the isolated lab.

The Academy banner for “CSRF where token is not tied to user session” shows Solved after delivery to the victim.
The Academy banner for “CSRF where token is not tied to user session” shows Solved after delivery to the victim.

Impact and defensive lesson

The evidence demonstrates the concrete risk of csrf where token is not tied to user session: a server-side trust decision can be bypassed through the exact input or workflow shown in this lab. For csrf where token is not tied to user session, the server must enforce the exact invariant violated in the captured sequence and regression-test that mutation alongside the normal path.

References