How does Anti-CSRF token get delivered?



  • 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/



  • 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.


Log in to reply
 

Suggested Topics

  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2