Antiforgery token in a distributed SPA application

Question

I am working on a distributed high availability single-page-application which gets served from a cluster of docker nodes. Occasionally a node will die (for perfectly valid reasons, so that is not the issue). All the clients get then seamlessly rerouted to one of the other nodes. Unfortunately, all of their XSRF tokens are then invalid, as they were stored in memory in the client.

The question is, thus, how can we distribute storage of the current XSRF token(s) in a *nix based setup?

What do you want to do with the XSRF tokes in an SPA?!?? It's called SPA, Single Page Application. The page consists of just a bootstrapper for the SPA, once loaded there are no new requests, just json or xml requests to a rest api. for these you don't use cookies and instead should send the token with EACH request (via SSL of course). There is nothing that can be forged when you implement the RESTful service that way. — Tseng
With a short and long lived token (access and refresh token respectively), you can mitigate it. Protecting against xss can also be done via http-only cookies See Jeff's post on it if you for some reason must use cookies — Tseng
Plain assumption based on your requirement. Why else would you want XSRF? XSRF against an WebAPI/Restful Api would only work when you don't pass a token with each request, and that means, sending a cookie. XSRF is for MVC-esque. For example if there is an "order form" on your website and I copy that html code, put it on my own website but with form "action" to your website and then lure a user to my fake page, and fill that form hidden and send it when a user clicks to redirect him to your website and fire an order. Without XSRF Tokes that would succeed if you were logged in — Tseng
since the form would be redirecting the user to your website, and send the form and with it the cookie when they are logged in. For that reason you need XSRF which changes on each request hence the attacker unable to perform this. but when you have an SPA, you typically call into an Rest-service/rest api and don't use cookies, so the above wouldn't work. So the question is: WHY do you think you need anti-XSRF-token for an SPA? — Tseng

Tseng Tseng · Accepted Answer · 2018-01-26T13:39:20

To summarize my comments:

XSRF/CSRF is only possible when you use Cookies for authentication. It allows attackers to lure users to a fake page which redirects a (typically hidden) form to your website with data filled by the attacker or by calling scripts in image tags (if get requests have side-effects, which should be avoided) , i.e.

<image src="http://yourdomain.com/user/5/delete"/>

When you use SPA (Single Page Application, Applications written in JavaScript where they are loaded only by the initial request and every other call happens via Ajax/JavaScript), then you would typically use Access Tokens (opaque token or jwt tokes) to authenticate.

Sending Tokens with each request is not vulnerable to XSRF, only if you use cookie authentication. The ASP.NET Core documentation explicitly states that:

https://docs.microsoft.com/en-us/aspnet/core/security/anti-request-forgery

Some attacks target site endpoints that respond to GET requests, in which case an image tag can be used to perform the action (this form of attack is common on forum sites that permit images but block JavaScript). Applications that change state with GET requests are vulnerable from malicious attacks.

CSRF attacks are possible against web sites that use cookies for authentication, because browsers send all relevant cookies to the destination web site. However, CSRF attacks are not limited to exploiting cookies. For example, Basic and Digest authentication are also vulnerable. After a user logs in with Basic or Digest authentication, the browser automatically sends the credentials until the session ends.

Antiforgery token in a distributed SPA application

1 Answers