How to use CSRF tokens correctly?

Question

Information Security

There was a task to close holes in already ready PHP application (big enough). After a short search, I was convinced that the only correct solution to close the CSRF vulnerability is to use one-time tokens. I put tokens on all POST requests, and everything seems to be super. But!

Nowhere is it really explained what to do if a request comes without a token. Somewhere it is advised to send "forbidden" somewhere in general 404. Somehow it is possible and so. But what about the F5 button? There, an already obsolete token is sent.

Search for example passes through POST too. And if the user wants to repeat the search, he refreshes the page, and he is thrown out to hell in the middle of nowhere. From the user's point of view, this is not entirely logical.
Same with browser history.
If there is a wizard, and the user returns to the previous page through the browser's "Back" button. If you throw it on a 404 or the main page, it will lose all the data that it entered.

Is it just me having these problems? Does anyone know a nice solution?

Answer 1

We personally issue a token at the login and are stored in the session. Why generate a new token each time?

Answer 2

It is enough to have one token per session. If the token does not match, the message “An error has occurred. Please check the entered data and submit the form again.
Naturally, the message must be shown along with the form with the filled data, and not on an empty page.
GET forms that don't make changes to the database, like a search form, don't need to be protected.

Answer 3

See how it is implemented in frameworks. For example Symfony, YII, etc.
Usually the logic is as follows: in the controller action with the form, we check - if POST (it means the form is being saved), then we check the token. If the token does not match, then we simply do not save the data, but display the same form but with the "Invalid token" error.
And tokens are commonly used in forms when saving data. For the search form, I see no reason to use them.

Answer 4

Don't refresh the token after each request, expose it along with authorization cookies.
About F5 - you can translate header(Location:/) after the request where appropriate, or use AJAX with the same token

Answer 5

The client in the search can indicate some personal data that should not get to a third party, no matter what happens next, therefore they should not fall into the URL (GET).