too strict / limiting workflow assumptions?

Issue #4 new
Thomas Waldmann
created an issue

Note: I didn't practically test this, but looking at the code (while working on CSRF-protecting a non-flask based app), there seems to be a severe problem.

In the code, you're popping the csrf token from the session (so it is not there any more after that code executed). Thus, the first generate call will create a new and different token and store it into the session.

This seems to assume that the only possible way to use a web app is:

  1. get (a form X)

  2. post (the form X)

  3. get (a form Y)

  4. post (the form Y)

Imagine you work with multiple browser tabs and you first do both gets and afterwards both posts, then at least one post will fail as the session only stores one (the last generated) csrf token.

There also can be lots of other scenarios making the strict assumptions fail (e.g. lots of ajax requests generating forms, people using the back button to resubmit a form, ...).

So, what can be done to solve?

a) remember lots of tokens we generated. While this would be possible, you basically never know how many you'ld have to remember. It would also inflate the session and slow down processing as it would have to compare the token it got against all tokens it has remembered. This sounds rather troublesome, esp. when considering that flask's SecureCookie based sessions offer limited storage capacity.

b) do not pop the token from the session, but just get it. This will lead to a session-long static csrf token. While not as safe as random tokens, this is still enough to prevent csrf and enables non-trivial workflows, using the back button, etc.

Comments (1)

  1. Log in to comment