How does Anti-CSRF token get delivered?

Question

I was reading an article describing how CSRF works. The article did a pretty good job but it started to talk about how to protect against CSRF and one of the methods that the article has mentioned is using Anti-CSRF tokens. I'll quote the section below:

Use Anti-CSRF Tokens Tokens (also known as synchronizer token patterns) are a server-side protection where the server provides a user's browser with a unique, randomly generated token and checks each request to see if the browser sends it back before carrying out a request.

This token is sent via a hidden field and should be a non-predictable, random number which expires after a short time and cannot be reused.

Depending on the sensitivity of the page, different tokens can be used for each request, or simply for different forms. The tokens should be compared in a safe way (such as by comparing hashes) and should not be sent in an HTTP get request so they are not a part of the URL and cannot leak via the Referrer header.

In the third paragraph it says the token should not be sent in an HTTP get request, which I understand (otherwise the token can be leaked). But If the anti-csrf token isn't delivered to the browser via the get request or any of the REST requests (PUT, GET, POST etc), what would be the method to deliver the token such that it cannot be leaked?

The full article can be found here: https://www.freecodecamp.org/news/what-is-cross-site-request-forgery/

Answer 1

I think you are misunderstanding some things. GET, POST, PUT etc. are HTTP request methods, used to send data to the server from a client. They are not used to send data to the client, nor do they affect how it is done.

This token is sent via a hidden field

Your quote describes one way a token may be sent to the browser, in a hidden HTML input field that will be submitted with the form. There are also methods that involve sending it to the browser in a cookie in addition to the form field, as in the stateless "double submit" method. I suggest you see the OWASP cheat sheet for CSRF to see more details.

Usually, CSRF protection isn't needed on GET requests not because it's a security risk itself, but because there isn't any CSRF risk in a GET request if it doesn't change state.

Answer 2

I think the 3rd paragraph is kind of misleading. GET Requests shouldn't require CSRF tokens in the first place, because GET requests shouldn't be able to trigger any action that could be malicious if triggered without your intent. However, if they do, sending CSRF Tokens along with GET Requests as URL parameters is kind of okay, if they are not able to leak e.g. via referer or link copy. This is usually the case if the target URL doesn't respond with content but e.g. with a redirect and when the request is initiated not via a link, but via api (e.g. fetch()), a form or dynamically via javascript. In these cases the target URL cannot be a referer, nor can it be copied. In this case I don't see a way they could leak, so it should be fine.

So, in conclusion, sending them via GET is bad practice but not insecure in general.

As mentioned, other request methods like POST are safer and usually are the ones that need CSRF protection the most, because they usually alter data / trigger serious actions.