Login CSRF Account Takeover: How Attackers Force Your Session

Login CSRF Account Takeover: How Attackers Force Your Session

Login CSRF does not steal the victim’s password. It logs the victim’s browser into an account the attacker controls. That sounds harmless until the app stores private data on “whatever account is in the cookie,” or until you chain it with self-XSS, OAuth linking, or payment methods added mid-session.

The basic attack

Attacker creates account attacker@evil. Victim is browsing while logged out (or after logout). Attacker’s page auto-POSTs to https://target/login with the attacker’s credentials. Browser follows redirects; victim now holds the attacker’s session cookie.

Anything the victim pastes, uploads, or connects under that session lands in the attacker’s account. Think: “connect GitHub,” “import contacts,” “save card,” chat messages drafted into a ticket.

When bounty programs care

Pure login CSRF without a data sink often gets marked informative. Pair it with impact:

• Victim uploads a resume or KYC file into the attacker’s account
• Victim links OAuth / SSO to the attacker-owned local account
• Chat support widgets attach the transcript to the attacker identity
• Attacker later uses a stored XSS in a profile field the victim is induced to view while “helping debug”

I’ve filed login CSRF alone on banks and identity providers where session confusion is itself a policy violation — read the program’s CSRF rules first.

How to test quickly

1. Two browsers. Create account A.
2. From a third origin page (or Burp Collaborator-assisted form), POST login credentials for A into the victim browser that was logged out.
3. Confirm the victim browser can see A’s private resources without typing a password.
4. Document missing CSRF token, missing SameSite on the session cookie, or acceptance of login via cross-site POST.

Check SameSite=Lax vs None. Lax often blocks cross-site POST login in modern Chrome; Safari and embedded webviews differ. Also try GET-based login endpoints if the app still has them — they are easier to trigger with an image or redirect.

Chaining ideas that raise severity

Forced login → victim binds a phone number → attacker removes the email factor from account settings. Or forced login → victim pastes a password-reset confirmation. Or attacker plants HTML in a “display name” and uses login CSRF to walk the victim into executing it in a privileged context.

Logout CSRF plus login CSRF can shove a logged-in user into the attacker account without consent. Test logout CSRF as a sibling finding.

Fixes that close the class

Anti-CSRF tokens on login. SameSite=Lax or Strict session cookies. Prefer login flows that cannot be completed by simple cross-origin POST (WebAuthn, redirect-based OIDC). Re-auth for sensitive linking actions even if a session already exists.

Map the issue to OWASP CSRF and CWE-352. For the takeover narrative, spell the user journey in numbered steps — triagers approve chains they can replay without imagination.

If your report stops at “login has no CSRF token,” expect a shrug. Show where the victim’s data went.