Your App Is NOT Secure If You Don’t Use CSRF Tokens

Cross Site Request Forgery (CSRF) is one of the most common security vulnerabilities that most sites face, but many people don’t actually protect from it. In this video I will show you what CSRF is, how to protect against it, and what could happen if you don’t.

📚 Materials/References:

🌎 Find Me Here:

⏱️ Timestamps:

00:00 - Introduction
00:52 - Project Overview
02:42 - How CSRF Works
05:15 - How To Fix CSRF Vulnerabilities

#CSRF #WDS #WebSecurity

[cristianlaspina]

Hello Kyle, in my understanding CSRF exploits have nothing to do with CORS.
Instead they are related to the "SameSite" policy of your cookies.
In your example server you've set the SameSite policy of your cookie to "none", doing so you're vulnerable to csrf unless you implement a csrf token as you showed us.
BUT if you hadn't set samesite policy in your server, Chrome (and I think all the other major browsers) would have automatically set that cookie to have a "Lax" policy which would have prevent csrf attack even without a csrf token.

That's my understanding from what I was able to experiment in the past. Please correct me if I'm wrong.

I usually don't write comments, but I'll take the opportunity to thank you for all you contents. They have been incredibly valuable for me :)

[andrewshirley]

CORS does not increase security. CORS, specifically, is an opt-out of security policy. The *default* policy of modern browsers is a same origin policy, and if you want to allow origins beyond that, you need to configure your server with a CORS whitelist policy that says "Oh, these places are allowed too." As others have stated, this vulnerability is entirely due to the cookie's SameSite setting, where "None" was the old default (meaning other sites could send requests to your origin and have it pass along any relevant cookies). The new default is Lax which only passes such cookies on a navigation action (meaning it doesn't return data to the malicious site), and you could even specify the SameSite policy as Strict to only ever be sent when you're already on the cookie's origin site.

Now, you can still do weird stuff and end up with a CSRF vulnerability. For instance, you can have an endpoint that allows a GET request but performs actual actions on behalf of the user, allowing malicious sites to attack this way even on a navigation action. But the more appropriate response is using the correct HTTP Verb bindings instead of going all-out with CSRF tokens, I think.

As to why your attack worked-- localhost is the same site as localhost, even if it's a different port. If you had 2 or 3 different computers and hosted the login site and the malicious site on two different computers, I don't think this would work.

[stytch]

Great video! Auth is so important to get right and has so many pitfalls that you can fall into. Love to see content like this helping up everyone's security game!

[TylerTraverse]

SameSite policy on cookies and checking origin/referrer headers is a cleaner solution that csrf tokens in my opinion, unless you make an API with some ridiculously bad GET requests.

[TanelM]

If you don't use subdomains or multiple sites on the same domain, same-site:strict cookies are enough. It's still good to use a CSRF Token if you're not sure where the client's going to deploy your web app - they might have a statistics site or some other tool on a subdomain with an XSS.

[ilijanl]

The drawback of this approach is that you need to implicitly include the csrf token in every form/http post and validate it in backend, which can easily be forgotten. A better approach is to use refresh tokens and access tokens. Refresh tokens are stored in http only cookie which can only retrieve access token (and refresh themselfs), and access token are stored in browsers memory (like you do with the csrf token) and used to call the API's.

[karanb]

Thank you, I've been researching CSRF from a developers POV, this really cleared things up. Just one thing to point out that CORS is actually to impose relaxations on Same Origin Policy. We can do this using Access-Control headers. Subscribed for more such content.

[Venistro]

When you have a SPA and do all requests with ajax, you can just send a custom header and check for this custom header to prevent CSRF.

[anasouardini]

sounds the like the refresh-token method. although they both do not eliminate the risk of a malicious attack they just reduce it.
also whether you know that there is a risk of being "hacked" or not, you always assume that it's the case. so not a single app on the earth is secure 100%. it's only a matter of making harder.

[thomasmiller]

Very clear, and fun. So in summary the main issue being other sites can use the targeted sites cookie. And by storing a token as a variable it's not accessible from other sites.
However in the current example if the user refreshes there page they would lose the token and need to re login. Or should that token be stored in the browser?

[jataman]

It's a very nice explanation but I still have several doubts.
1. If the server checks the CSRF token, why does it need to check also the session if we are sure that the request is done by a logged-in user from their browser?
2. Isn't setting SameSite option in the cookie enough? If not, why?
3. If the CSRF token is stored in js, it's lost after refreshing the site, right? Can we prevent it?

Thanks!

[unknotmiguel]

I would no use a token on cookie. But maybe local storage since that is not sent automatically with the request. The request requires to add that param from local storage manually... That would solve this issue

[najwer]

i had a lot of question about csrf and you answered all with that one video

[calebkrauter]

Great video. Shared it with my dev buddies in college. Thanks!

[ganeshchowdhary]

Great, one way is that server can pass a JWT token which the logged in client can save and use it in the future requests. Hence using secure tokens such as JWT, prevents CSRF attacks.

[geforcesong]

This is the note taken from MDN. Maybe we don't need implement it on our own in modern browsers.

Note: Lax replaced None as the default value in order to ensure that users have reasonably robust defense against some classes of cross-site request forgery (CSRF) attacks.

[jarrayamehdi]

Hello Kyle, thank you for this tutorial, I think another alternative to prevent the evil site to access is to set cookie sameSite to lake

[phdz]

I think if you ask the user to send back his username or password with the request to delete a ressource, in this case you're protected against CSRF, as the evil site or page doesn't know them even if the cookie is auto sent by the browser, in other words the username or password will act as a CSRF token, because at the end a csrf token is just another secret that you're posting and keeping in a variable in memory and sending it back throught the clients request.

[roronoa_d_law]

8:30 but if the token is sent only when the user logs in and you don't save it in local storage, he will lose it if he refreshes the page after being logged in

[cadillacjack]

Your content is dope. I've learned a lot of stuff from you. Thank you