6

I'm trying to find an answer to the following.

  • Under what circumstances would the browser store multiple csrftoken cookies?
  • Is it the correct, or technically valid functionality?
  • And where in the RFC/security documentation passing an array, or trying an array of csrftoken exists, or is technically valid?

I've attached an example screenshot of what I'm seeing multiple csrftoken with various cookie paths, and expiry times ( multitenancy, and various form paths ).

enter image description here

Related:

jmunsch
  • 22,771
  • 11
  • 93
  • 114
  • Can you show how you are setting the token required parameter for the POST request? It's somewhere confusing to understand your screenshot, wherein, I can't seem to understand the righthand side of the screenshot, wherein, you are showing the csrftoken for different paths with the `LastAccessed` – Nagaraj Tantri Jan 20 '20 at 02:10

2 Answers2

1

It is not a requirement to only have one token, but a more common approach would be to update/refresh CSRF token cookie on a single root path: /.

It really depends how your server interprets the potential forms posts that follow each token request. An easy approach is to store a newly generated token on a user's session storage (in memory or database) before setting the cookie. Then compare these two again on the server when the user's form POST arrives.

  1. The browser stores multiple token cookies when each HTTP GET request (which responds with a token) specifies a custom cookie path. A more common approach would be to have one cookie for the purpose of protecting against CSRF.

  2. You could make your tokens path specific, but this would not make your token more secure.

  3. Testing token validity is entirely up to you.

Hope this helps.

gwest7
  • 1,556
  • 19
  • 26
1

Here tokens are stored in cookies. Cookies are unique per their Scope (Domain and Path) and cookie name.

In this case all cookies have same name - csrftoken, they also have same domain - 127.0.0.1, but path is unique for each cookie. So, different scope (more specifically, path) allows to have multiple cookies.

The most referenced and respected document describing protection measures from CSRF attack is OWASP Cross-Site Request Forgery Prevention Cheat Sheet (GitHub Markdown variant).

Generating one csrf token per user session and storing it in a cookie is most popular approach. Being associated with session makes it somewhat protected from cookie-altering. Note, that you should use additional methods (i.e. double submit cookie and also include token in request body) for protection, because cookies are sent automatically on request.

Session altering views (login / logout / password change) and other important and high-security views (i.e. money transfer) may and should be protected with advanced and / or additional techniques (i.e. user interaction).

Why multiple csrf tokens were returned?

Possible explanation of back-end behavior: it may be an attempt to add graphql support to the app. It also looks like a combination of graphql with rest.

A request was made to /graphql endpoint, which in turn traverses all other rest api endpoints as if future POST / PUT / PATCH request may be made to them, each of the endpoints / view add its own per-path / per-form (or even per-request) csrftoken cookie to the response. Also, it looks like with this approach, next request is expected to be not to the /graphql endpoint, but to one of the rest api endpoints / views url directly.

With Graphql you will have only one /graphql endpoint and all requests will be made to it.

Also, having multiple csrf tokens (per endpoint) does not give much if any advantage.

For a way to add Graphql API to django - check Graphene

And if you are looking at using separate front-end app with Django back-end you should definitely take a look at django-cors-headers (and use it).

Oleg Russkin
  • 4,234
  • 1
  • 8
  • 20