Anti CSRF tokens - explained

Why we should protect web forms and other sensitive links on websites using CSRF tokens. Describing protection tokens using: sessions and double cookies submission methods. Useful for ensuring secure client-to-server communication coming from a trusted source.
💖Support on Patreon:
/ nneykov
----------------------------------------------------------------------------------------------------------------
👥 SUBSCRIBE! ► www.youtube.com... ◄
----------------------------------------------------------------------------------------------------------------

[@Michal_Silski]

HttpOnly cookie doesn't prevent from CSRF. In case you described, if attacker knows API call structure it is still possible to redirect the user to the external site from where malicious API call could be automatically submitted (it includes both cookies so server validates it successfully). To protect against CSRF you need to include csrf token both in cookie and in http call parameter to API.
HttpOnly can be used rather as protection against XSS.

[@NevyanNeykov]

I am describing the usage of double submit cookie technique against CSRF. Of course with enough effort it can be bypassed with some kind of MITM attack. The former together with the protection against XSS is a sole responsibility of the application developers.

[@Michal_Silski]

@@NevyanNeykov Thanks for response. Refering to OWASP Cheat Sheet Series
Cross-Site Request Forgery Prevention guide - (Double Submit Cookie section) it is necessary to include a csrf token in http request parameter/header (besides in the cookie). Without that server is not able to verify if request originates from the client or from malicious page. I missed this information in the video or I misunderstood your idea.

[@khoroshoigra8388]

best thing there is to get the IP address to as basis of request from the client as another verification

[@NevyanNeykov]

not quite, as it can be easily spoofed.

[@xoxo1171]

Thanks you

[@NevyanNeykov]

Welcome

[@ravindrabhatt]

why will the attacker modify xcsrf cookie before sending?

[@NevyanNeykov]

can you elaborate your question a little bit?

[@ravindrabhatt]

@@NevyanNeykov Sorry for not being clear. At 2.46, Is the session token and CSRF token same? Also, at 5.22 you mentioned, attacker can try to modify the xcsrf cookie, so my question is why will attacker try to modify it? as he can just send as if it is and server will not be able to recognize who is real and who is the attacker. Or, Is there any other information of interest, embedded in the second cookie which is causing the attacker to modify it?

[@NevyanNeykov]

Yes they are the same. The attacker wants usually to forge the information inside the cookies/tokens and when doing so the xcsrf check will be triggered and be invalid.

[@user-ob4nr7ry6u]

Thank you, if i use jwt token then csrf is needed ?

[@NevyanNeykov]

Correct practice.

[@vlegend.5516]

So the web browser can generate the original crsf token and be valid?

[@NevyanNeykov]

the browser need to guess the crsf cookie to be matching the original session cookie, which is quite difficult if is not the original set from the server.

[@yura41]

I still don't get it

[@NevyanNeykov]

it is not easy.