0

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?

Giuseppe Maggiore
  • 2,011
  • 1
  • 23
  • 31
  • 2
    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 Jan 24 '18 at 08:47
  • 2
    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](https://blog.codinghorror.com/protecting-your-cookies-httponly/) if you for some reason **must** use cookies – Tseng Jan 24 '18 at 08:50
  • @Tseng, where do you see any mention of cookies in my post? – Giuseppe Maggiore Jan 26 '18 at 11:35
  • 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 Jan 26 '18 at 13:17
  • 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 Jan 26 '18 at 13:20
  • TL;DR: Anit-XSRF-tokens: For MVC and Razor pages, yes. Good and required. For SPA with WebApi? Pretty much useless unless you authenticate via Cookie (rather than sending the access token/jwt every request) against the WebAPI), then you should rather change that ;) – Tseng Jan 26 '18 at 13:22
  • Also please have a look at the documentation: [](https://learn.microsoft.com/en-us/aspnet/core/security/anti-request-forgery): _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._ – Tseng Jan 26 '18 at 13:32

1 Answers1

1

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://learn.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.

Tseng
  • 61,549
  • 15
  • 193
  • 205
  • Mind to comment the downvote? XSRF is only a concern when forms are used or mutable get-requests. SPAs don't require it unless they or the background api is implemented horribly wrong. OP requires to correctly understand XSRF and not look for a solution to a wrong question/approach – Tseng Jan 31 '18 at 12:13
  • You can send the token in httponly cookies aswell.. Actually it is preferable since mitigating CSRF with another token is trivial compared to fixing potential xss vulnerabilities you expose yourself to by having your auth token in memory/localstorage/httponly=false . – SomeRandomName Jul 11 '19 at 06:28
  • @SomeRandomName: Always depends. Usually it's a bad practice to use cookies on WebApi-styled applications, since XSRF is a bit of a pain and generally XSRF is easier exploitable than XSS. Handling XSRF tokens inside ajax requests can be a bit of a pain too, cause you need to request the token before you perform some action (change a persons address for example) and pass that one with the request that do the changes. In ASP.NET Core MVC thats done as part of loading the form, in SPA applications well you don't load the form every time (i.e. when creating the user for the first time) – Tseng Jul 11 '19 at 08:56