Opened 3 years ago

Closed 3 years ago

Last modified 3 years ago

#33522 closed New feature (invalid)

Unexpected behaviour when logging in

Reported by: Michael Owned by: nobody
Component: contrib.auth Version: 4.0
Severity: Normal Keywords: authentication log in CSRF token
Cc: Florian Apolloner, Shai Berger Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description (last modified by Michael)

Say a user opens two tabs to the same site, both show the login page.

The user logs in on Tab A, does some things, after a while changes to Tab B, sees the login page, and instictively clicks login (their details pre-populated due to auto fill). They will then get a surprising CSRF error.

I thing this is because when they logged in on Tab A, it deleted the anonymous session, and replaced it with a new session, which means the CSRF token from Tab B fails.

Would it not be better to not delete the anomyous session when one logs in, or upgrade the session (instead of deleting it)?

Change History (10)

comment:1 by Michael, 3 years ago

Description: modified (diff)

comment:2 by Michael, 3 years ago

Description: modified (diff)

comment:3 by Michael, 3 years ago

Type: BugNew feature

comment:4 by Michael, 3 years ago

Resolution: invalid
Status: newclosed

It seems like pre-login session token, and creating a new session is required for security due to my research, so this suggestion is invalid.

I think the solution is to create a custom CSRF view that if there is a CSRF failure, you redirect the user to the page they want to see in the first place, and it will now work cause they already logged in.

comment:5 by Michael, 3 years ago

Here is the solution I posted if anyone else has this issue: https://stackoverflow.com/a/71174489/5506400

comment:6 by Michael, 3 years ago

Resolution: invalid
Status: closednew

Thinking about this some more, what if the CSRF middleware got the token from the cookie, instead of from the form data? This would solve the CSRF errors that pop up every now and then.

comment:7 by Mariusz Felisiak, 3 years ago

Cc: Florian Apolloner Shai Berger added

comment:8 by Carlton Gibson, 3 years ago

Resolution: invalid
Status: newclosed

Others can comment, but this looks like exactly expected behaviour to me. I'm not sure we can, or it's worth trying to work around.

I don't see that we're ever going to be able to update forms rendered before a login with a fresh CSRF token. (Some JS maybe, but it's not clear that's going to be 100% safe ever.)

... what if the CSRF middleware got the token from the cookie, instead of from the form data?

This would totally defeat the point no? I get you to submit a form from my evil site to yours; your browser sends the cookie; the only thing that saves you is that I don't know the right token to add to the form data.

comment:9 by Florian Apolloner, 3 years ago

Thinking about this some more, what if the CSRF middleware got the token from the cookie, instead of from the form data? This would solve the CSRF errors that pop up every now and then.

Then it would compare the cookie against the cookie providing no security :) It has to compare the cookie (something the attacker cannot control) to the POST data (or header as fallback).

comment:10 by Michael, 3 years ago

Sorry yes that would be pointless.

With the "SameSite: Lax", and some JavaScript to set the X-CSRFToken header, and not use GZIP for HTML responses (I think the masked CSRF Token is to counter BREACH attacks), I think it would mitigate CSRF token errors, and be just as secure. I understand the Django admin site is not keen on JavaScript, so its up to custom code if one prefers that.

Note: See TracTickets for help on using tickets.
Back to Top