2

I know

this question has already been asked so many times, but after hours of searching I still don't have a clear answer to my problem.

Even projects like https://github.com/pillarjs/understanding-csrf have been abandoned and have not answered to new questions and doubts over the years like this.

PROBLEM

Let's say I have:

  • a back-end on back.domain.com and
  • a front-end on front.domain.com.

My back-end is a simply nodejs app with these rest endpoints:

  1. POST /login:

    1. accepts JSON body like: {"username": "myname", "password": "mypass"}
    2. verify credentials
    3. if OK gives 200 and create a cookie with session
    4. if NOT gives 401
  2. GET /players:

    1. check session in cookie
    2. if OK gives 200 with {"players": "[...]"}
    3. if NOT gives 401
  3. POST /player/1:

    1. check session in cookie
    2. if OK gives 200 and edit player
    3. if NOT gives 401

My front-end app has:

  1. /login page with a form (with username and password fields) for issue a POST request to back.domain.com/login

  2. /players which request a GET request to back.domain.com/players

  3. a button which issues a POST request to back.domain.com/player/1

QUESTIONS

  1. Do I need CSRF protection in this scenario?

    I think YES, I need because an attacker can issue a request to back.domain.com/player/1 from malicious.site.com and use my session cookie to edit player because I'm logged in (and I still have a session cookie) on my domain.com.

  2. Do I need CSRF protection (e.g. an X-CSRF-Token header) when I the first time login on back.domain.com/login?

    1. In this scenario I still don't have any session cookie in my browser.
    2. And also I don't know where to get my CSRF token for X-CSRF-Token authorization header too.

    I read on https://fractalideas.com/blog/making-react-and-django-play-well-together-single-page-app-model they are creating a dedicated endpoint on back-end for this and they explain it's not a security vulnerability.

What do you think about?

Fred Hors
  • 3,258
  • 3
  • 25
  • 71
  • I'm not able to answer the question, but I got a similar scenario and would like to know whether you got any new insights. – tg24 Jan 16 '20 at 07:12

1 Answers1

2

You are correct.

You DO need CSRF protection any time BOTH of the following are true:

  • the browser is automatically providing the authentication mechanism (most common way this is done is with a cookie)
  • the operation is state-changing on your backend

Of your three endpoints, only one meets both of those conditions.

GET /players/: get is not a state-changing operation. No CSRF protection needed.

POST /player/1/: authentication provided by cookie; post is state-changing. Needs CSRF protection!

POST /login/: the browser is not automatically providing the authentication information; it’s coming from data the user has intentionally typed in and submitted. No CSRF protection needed.

You’ll find other schools of thought - this other stack overflow post indicates the possibility of privacy-violation attacks, but the method described stretches credulity a bit in my opinion. And in any case you are right - if your frontend and backend are being served by totally different servers, your frontend won’t have the CSRF token before the user logs in.

Daniel Smedema
  • 919
  • 8
  • 15
  • Can you specify more on the meaning of state-changing endpoints ? – aravind ks Feb 01 '22 at 17:23
  • If making an HTTP request could result in data being changed on the server, it is "state-changing". Usually anything besides GET, HEAD, and OPTIONS. Technically a server can do whatever it wants with any HTTP request, so you could implement an endpoint that changes server state in response to a GET request, but to abide by the spec properly, you wouldn't do this. It's highly recommended to abide by the spec because browsers will do things like caching and preflight requests and so on and will assume some HTTP verbs are safe. https://developer.mozilla.org/en-US/docs/Glossary/Safe/HTTP – Daniel Smedema Feb 01 '22 at 19:43