CSRF protection. How correct is the approach?

Question

PHP

I came across CSRF and was a little puzzled by this problem. What is the best way to organize protection against request spoofing?
After reading a couple of articles on this topic, I realized that the best way is to send a unique token along with the request.
And so, while there is such scheme:
At authorization to write down to the user in session unique token. Then, on the pages that require sending a request, add a hidden field to the form and pass the same token through it. After that, before processing the request, check the token itself. But how to check it, because I read that checking a token for isset is not good.

Answer 1

1) we create a token
2) we write to the session
3) we add it to the right places in the views. for example, hidden-fields in forms or set some header if requests are made via AJAX
4) with each POST / DELETE / PUT / PATCH requests, we check the input token and the token in the session. did not match = yet.

Answer 2

Since the interaction with the server is a request / response, the tokens will only allow you to determine that there may have been a substitution. They will not save you from the change itself.
For example, you have implemented:
1. Generated and saved the session id and token on the server.
2. Transferred to the client.
3. The client makes a request to the server and passes the session id and token
4. You check the value of the token id. If correct, then generate a new one and save.
5. Everything is returned to the client.
- And now the user used the site and left without closing the session. The attacker will simply continue to use his session and token. Until the wrong token arrives, you won't know.
- Another problem. A request went to the server with the correct token, but for some reason did not return. Retrying a request is no longer a valid token. Also multiple ajax requests at the same time. Again not valid. Problems for you both as a developer and as a user.

Answer 3

When authorizing, write a unique token to the session for the user.
generally fine, but it is better not to tie the creation of a token to authorization, because CSRF can be before authorization, for example, CSRF for authorization itself. Create it directly when creating a session. At the same time, in order not to store the token on the server and not create it explicitly, you can generate it as a hash, for example MD5(sessionid,secret) - where secret is a key known only to your server, which can be changed if necessary. Otherwise - yes, use it as a hidden field in all forms or as a header in ajax requests. But if you use it as a hidden field in forms - avoid GET requests, because this could potentially expose the token via the Referer.