Token Exposure in URL

Corveil's sign-in handler drops the new session token into the redirect URL. An attacker harvests live tokens from a partner's referrer log and replays one to walk into a victim's account, then you ship the HttpOnly-cookie rewrite.

What Is Token Exposure in URL?

Token-in-URL is the special case of the URL-as-data-channel anti-pattern where the value being leaked is itself an authenticator. The URL travels through server and CDN access logs, browser history, the Referer header sent to every third-party asset on the resulting page, and link-preview unfurlers, and anyone with access to any of those transports holds a string that authenticates them as the user for as long as the token is alive. Common offenders: legacy SSO callbacks that redirect to /dashboard?sid=... , password-reset URLs that carry the token in the path (where it is also logged), download URLs signed with the user's session, and magic-link sign-ins. This exercise puts you on both sides. As Bob, you sign in to Corveil, a shared-workspace app, notice the session token dropped into the redirect URL, buy a third-party analytics referrer-log dump filtered for that URL pattern where every row is a live session token belonging to a real user, then replay one in the API Tester to read a victim's private documents with no password. As Alice, on the receiving end of a fourteen-sessions-replayed anomaly, you open the sign-in handler, see the redirect target carrying the token, and apply the fix: a Set-Cookie header that moves the token off the URL and into an HttpOnly; Secure; SameSite=Strict cookie, with a clean redirect. The exercise closes with quiz questions on why a token in a URL is worse than ordinary data in a URL, why HTTPS and encoding do not help, and why every already-leaked token must be invalidated even after the code is fixed.

What You'll Learn in Token Exposure in URL

Token Exposure in URL — Training Steps

  1. Watch a sign-in

    Bob has been poking at Corveil, a shared-workspace app that businesses run their documents on. Before he looks for a way in, he wants to see exactly what the app does when someone signs in. He registers a throwaway account so he can log in as himself and watch every step. He starts on the sign-in page.

  2. Sign in and follow the redirect

    Bob signs in to his throwaway account, the way any user would. His password manager fills the saved credentials. Corveil signs him in and redirects him to his workspace dashboard. The browser lands on the page it sent him to.

  3. The token is in the address bar

    Bob is on his dashboard now, and something jumps out at him: the sign-in dropped his session token straight into the URL. That one string is his whole logged-in session. He does not need to break into anything. He just needs the places these URLs pile up.

  4. Harvest the referrer logs

    Bob never sends Corveil a single malicious request. Instead he buys a month of referrer logs from an analytics reseller, the kind of vendor whose tracking tag sits on Corveil's dashboard and quietly records the full referring URL of everyone who loads it. He opens a terminal next to the browser and greps that feed for the dashboard sign-in links.

  5. Replay a stolen session

    Bob picks one victim out of the dump, Maya Okafor, and takes her session token. He points the API Tester at Corveil's document API and carries her stolen token in a Cookie header, exactly as her browser would. If the server accepts it, he is reading Maya's private workspace without ever knowing her password.

  6. Her session is his

    The server took the stolen token as a genuine login and answered. Bob is now reading Maya's private documents from a plain API call, with no account of his own and no password.

  7. Knowledge check

    Bob can do this for thousands of users at once, all from logs he bought. Be precise about why a token in a URL is so much worse than ordinary data in a URL.

  8. The security alert

    You own Corveil's sign-in service. Overnight, detection flagged a run of sessions being replayed from unfamiliar locations and emailed you the finding. Read what it caught, then open the code.

  9. Open the sign-in handler

    The handler that finishes sign-in and redirects the user to their dashboard is what you need to change. Open it and look at how it builds the redirect.

  10. Spot the leak

    The handler mints a fresh session, then pastes its id straight into the redirect target's query string. The browser follows that URL, and from that moment the token is everywhere the address goes.