CSRF False Positive when Logging in From Other Screen Simultaneously

[Klaas van Schelven]

Consider the following scenario:

• Go to a login page (e.g. standard contrib.auth stuff)
• Open another tab and go to the same page
• Log in from the first page
• Log in from the second page

You will now be presented with a CSRF error. I would consider this a false positive.

In my understanding CSRF protects against data which is crafted on other domains (controlled by the attacker) and are then posted to the server.

In other words, it should protect against cases in which data is POSTed to the server which was not first presented to the user by the server. In the scenario above, the data _was_ first presented by the server to the user. Hence this is a False Positive.

A similar scenario exists if the first login is followed by a logout. In this case I can make an educated guess towards the reason (namely: the full session is likely to be flushed on logout, causing any CSRF cookies to be deleted). However, I would say it's equally wrong.

I am not a security researcher - correct me if I'm wrong in all/any of the above.

[Aymeric Augustin]

I suspect this happens because we rotate the CSRF token on login and there's a good reason for doing so.

[Tim Graham]

Duplicate of #21704

[Klaas van Schelven]

I was somewhat unconvinced by the brief answers, qualifications such as "I think" and "I supspect" and quick closing above. However, the internet provides an answer as to why my reasoning above was wrong, and hence the closing is justified:

​http://security.stackexchange.com/a/22936

"""
There is one place where it is worth issuing a new CSRF token, though: on principal-change inside a session. That is, primarily, at login. This is to prevent a session fixation attack leading to a CSRF attack possibility.

For example: attacker accesses the site and generates a new session. They take the session ID and inject it into a victim's browser (eg via writing cookie from a vulnerable neighbour domain, or using another vulnerability like jsessionid URLs), and also inject the CSRF token into a form in the victim's browser. They wait for the victim to log in with that form, and then use another form post to get the victim to perform an action with the still-live CSRF token.

To prevent this, invalidate the CSRF token and issue a new one in the places (like login) that you're already doing the same to the session ID to prevent session fixation attacks.
"""

Specifically, the following part of my reasoning above is wrong:

"""[I]t should protect against cases in which data is POSTed to the server which was not first presented to the user by the server."""

The caveat I did not see was that, for forms that are shown pre-login, the server cannot make sure that the token that comes back was not first seen by others. (This is because this token is shown to everyone on the internet).

In yet other words: the token that's shown to a logged in user should be more secret than the token that's shown to any visitor of the site; hence they cannot be identical.

[Aymeric Augustin]

Sorry for the terse comment. It wasn't meant as a definitive answer, rather as a hint for the next person who would investigate the ticket.