Opened 8 years ago

Closed 8 years ago

Last modified 8 years ago

#24786 closed Uncategorized (duplicate)

CSRF False Positive when Logging in From Other Screen Simultaneously

Reported by: Klaas van Schelven Owned by: nobody
Component: Uncategorized Version: 1.7
Severity: Normal Keywords:
Cc: Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no


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.

Change History (4)

comment:1 Changed 8 years ago by Aymeric Augustin

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

comment:2 Changed 8 years ago by Tim Graham

Resolution: duplicate
Status: newclosed

Duplicate of #21704

comment:3 Changed 8 years ago by 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:

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.

comment:4 Changed 8 years ago by 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.

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