For those of us who are in the tank about CSRF?

I have read https://habrahabr.ru/post/235247/ and other articles on the resources smaller.
Now I have cookies placed on 1 hour in addition to the name cookie, nothing is stored in session are stored the email id and the session itself is not stored anywhere (except for temp servers of course).

If I understand correctly then:
1. The user is authenticated, authorization generis him a token and put in session
2. In any form have a hidden field which is populated token without the knowledge of user data from session
3. But during the reception form data from the form came a token must somehow compare to the original, otherwise you can send any and all this bessmyslenno. It turns out that would have been original to in paragraph 1 token should be written not only during the session but in the database from which for each scan to extract for comparison.
And to update it in the database at each login...
4. Get-requests a token cannot be protected
All so or I missed something?
July 9th 19 at 10:17

Related questions

More answers about "For those of us who are in the tank about CSRF?"
5 answers
July 9th 19 at 10:19
Solution
4. Get-requests a token cannot be protected

Possible, but not necessary. You should not take any action except content is served for a get request. For update/delete/create need to use POST if it's a classic web site and PUT/DELETE/POST if it's a RESTful API.

Let the client sends a csrf token in the POST request. Let the server at the start of the session, stores a csrf token in session. Let the server before performing a POST request will verify that the token from the request with the fact that in the session.

In the database the token to be stored redundantly. Saving a session you will always have access to the client to change it no way.
About GET but there is a remark that is sometimes the API and I have in this is the need which enable you to add any entity through the API to the database (of course, after authentication), or for this case, you just offer PUT to use? - alva8 commented on July 9th 19 at 10:22
Yes, you should not change/create/delete entities via GET, do it via POST or as is common in RESTful POST - create PUT - edit, DELETE - DELETE. The GET should return the data but should not modify them. - cassidy.Green commented on July 9th 19 at 10:25
July 9th 19 at 10:21
Solution
1) create the token
2) write to the session
3) add in the desired location in the vyuha. for example, hidden fields in forms or install any header if the requests are made via AJAX
4) each POST/DELETE/PUT/PATCH requests, check the input token and the token in the session. didn't match = while.
July 9th 19 at 10:23
Solution
The essence of a CSRF attack the attacker gaining data that will allow it to impersonate another person. And all you need to do to protect is to generate for each request a unique token, of course, with the entry in the database or in the current session and the execution of any request to verify the token and replace it. From this it follows that the token needs to be changed with every action of the user, not only at each login.

Storage time cook here not play any role. The user clicks "remember me", and you set it cook for an hour?

Actually, everything is pretty transparent, in my opinion. Maybe I missed something, in which case I will be glad to amendments.

Get-requests a token cannot be protected

Why? Sent to get the token parameter on the server check.
to generate for each request a unique token

And that one session will not ride? Because each new request is in fact updating the page is simple. It turns out I need to do update the token in the database is not authorization but simply when the page is refreshed - alva8 commented on July 9th 19 at 10:26
: I just realized at 4:44 https://www.youtube.com/watch?v=CWje5DWniDQ in humans, a token is changed, I provigil is a little... - cassidy.Green commented on July 9th 19 at 10:29
: no, in the essence that it needs to be disposable. Session can be long, and it is possible in any way to the token. In General, Yes, you can change each time the page is refreshed. - alva8 commented on July 9th 19 at 10:32
: Ahh, I randomly generate, put in session and form, and when form comes, I have to compare with what in a session? But here we must not fail and not generate a new token TO validate form )))) - alva8 commented on July 9th 19 at 10:35
: Yes, something like that) And about the second - it all depends on the architecture of the project as a whole) In principle, if the action processing and output of the shape answer different parts of the application, the problems should not be, because there is a clear separation. - Annabelle_Schoen commented on July 9th 19 at 10:38
July 9th 19 at 10:25
View towards ready-made solutions, like this:
https://github.com/BKcore/NoCSRF

If you want to understand how it all works, you can pick open the code of this library
For some reason no one stubbornly ignores the question )) I'm not interested in libraries interested in whether I understand the mechanism of protection... - alva8 commented on July 9th 19 at 10:28
For this I You below in the response added that it is possible to see how the library works. There will be easier to understand the mechanism of - cassidy.Green commented on July 9th 19 at 10:31
July 9th 19 at 10:27
Needs to be turnkey solutions, take a look at whatever is implemented, the type of asp mvc. To get better not to push, and in General it is better not to use AO in many places. If no session why there was a question about this vulnerability? Session is not stored-it's like? The token should match the session and for example way.
Again, I'm not interested in libraries are not interested in how it is implemented in asp, I am interested in the mechanism.
Session is not stored-it's like?

She is still living cook - 1 hour - alva8 commented on July 9th 19 at 10:30
Token is not to be stored can be stored, for example salt. - cassidy.Green commented on July 9th 19 at 10:33
The mechanism consists in checking the conformity of the request and session token . It is so clear, I think - alva8 commented on July 9th 19 at 10:36
: Go in theme With sharp finally )))) If I only store the salt, and a token is generated only from mikrotaym I NEVER will restore for comparison )) - alva8 commented on July 9th 19 at 10:39
Mikrotaym -what's that? The timestamp, I'm not talking about what microtime wrote . Look at any implementation, and all questions will disappear . Like to use constant token ispolzuyte. - Annabelle_Schoen commented on July 9th 19 at 10:42
: Educate:
$token = md5(microtime(true).rand(1,1000000)); - alva8 commented on July 9th 19 at 10:45

Find more questions by tags Information securityPHP