Hello and welcome to Secure JavaScript Programming with Vladimir de Turckheim. In this video, we will talk about CSRF, or Cross-Site Request Forgery. Sometimes I prefer to refer to the OWASP documentation, and that's actually a very good source of truth toward your journey as a secure programmer. I'll recommend you to learn about the Cheat Sheet Series from the OWASP. Today, we will focus on CSRF. CSRF happens when a malicious website actually performs operation towards another remote resource against which the user is authenticated. In other words, a CSRF attack works because browser request automatically include all cookies, including session cookies. If you have a formula on a website and you want to cross post at another website, well, this will work. The impact is limited by the application and privilege available on the target website. Let's take an example. Here, I've got my website to subscribe to my newsletter on localhost 3000. Here I've got another website that could contain a firm with totally all the data, but the user doesn't know that actually by doing that, they will post something on the other firm. If I do this, actually it's posted on the other website. We tricked someone into performing an operation from a website to another through formulas. This one is a very, very bad CSRF because you realize it immediately. But sometimes the examples must be easy associated. Eventually, CSRF can bring you all the capabilities of the attacked website with the credential of the user. Also, it's worth noticing that all the protection regarding CSRF can be bypassed if there is an XSS on the target website. Because in that case, the attacker doesn't need to craft fake websites to have you do operations. They can just run arbitrary code on the attacked website and use your token and your authentication privileges without having to do the cross website part. But we will go back to protections a bit later. One of the legitimate question is how can I prevent, as you know of localhost 3000, how can I prevent anyone from the other domain to parse in my own website? Well, here, let me find the right page. Here I've got the form on index.ejs. The historical solution when you've got server-side rendering is actually to add a new field in the formula, a field without label. I'll type text, which has the name csrf_token. I use an underscore because it's easier for me when we'll use it in JavaScript. Here you will add immediately your value. Since I am in a rendered template, I can use this. Now I need to update my controller to provide me with a token. Since I am a responsible citizen, I will use a strong token generation. For instance, UUID module NodeJS is pretty good. Also, on most recent versions of NodeJS, there are UUID generation directly on the crypto API. What we want is uuidv4. Yeah, I'm not a big fan of this because I am old. V4, I've got a UUID. But as you realize, well, I don't know if this one is valid. It doesn't make any sense. What I need to do is to keep in my database along with my session, the list of UUIDs.. Let's imagine that database, and instead of doing that, we will do this, add token. Now, we know that you have these field. If I restart the project, and we go back to the Express app, we see that we have a field up here. It's nice, it's good, but it doesn't do all what we want yet, and it creates weird user experience. The first thing we will do is, we will hide this field in the HTML, and though it's over and the form is back to be user friendly. Then the second part is to actually check the token. When we have a new subscription, we need to check that it is in the right list. Here, if req.body. I think I named it csrf_token const req.body.csrf_token if no csrf_token or token has const req.body.csrf_token. We put a navigation here. We check that if there is no csrf_token or if the csrf_token provided is not in the list of acceptable tokens, then we will just res.end, well tried. We need to return it so it's broken. Also, we don't want the csrf_token to live forever, so we need some way to remove them from the database after a while. For that, you need to use database that has expiration or all those tricks like that. I usually recommend using Redis for this thing, because you can put an expiration pretty easily on that. When the token has been used once, you need to remove it, so the user can't use it twice. This should actually give us what we want. My personal email address @world.com has of undefined. What did I do? Mistakes in live demos, my first code is actually to debug. I probably have a circle dependency import issue. Let me try that. That's just me being a terrible developer, because in this piece of code, I overwrite. So value of this that we have because auto-complete should be off so I should not have my e-mail address his. Like that. Let's go back. Hello, hello@world.com. Good thing's that my e-mail addresses are all public and that's no sensitive data and here it worked. If I go an all, I see that I have a subscription. But if I go on the user site, it's actually tells me that the CSRF protection blocked me from doing that. This is to recall way of blocking CSRF attack with the hidden field is actually pretty much updated because it's still works with PHP, with Ruby on Rails, with everything where there is server-side rendering. But in the modern world, you will probably have an EPI and record the front end application may be rendered several server side, but only at first rendering cycle if you're using stuff like Nextrials and you might have just a single page application. We use an API. That's not too bad. That's actually good news because there are ways to put the CSRF token actually in a cookie. You've got the csurf module in Node.js where the CSRF token is placed in the cookie and if you do that which is great, you must use same site, an HTTP only. Why is that? Because actually, if it's not HTTP only, anyone can use that same site. Anyone can use that too. If you have the same site to strict, no other websites, as long as the browser understands the same site flag of the cookie, no other website will be able to use this cookie. It won't be able to actually use it as a CSRF token, since it will be available only for your domain. It will refuse to use that. That's also one of the reasons why you want most of your cookies to be same site, because you don't want cross calls between the cookies. Another way to limit cross-site interactions is to disable and [inaudible] disable by default, Cross-Origin Resource Sharing. Depending on how your website is built, enabling Cross-Origin Resource Sharing might give access to certain functions of your websites if you are using non-standard way of building web applications. You also want to make sure that your web server does not accept CORS, Cross-Origin Resource Sharing and will deny all of them. If we check the recommendation by the OWASP, they also recommend to use HMAC token so you are sure that the token has been issued by you and signed properly. Yes, that's the very same point. You don't have to save the token, you can also use the same behavior as with a GWT or JSON web signature and sign the cookie, CSRF token. So you are sure that you issued it, and nobody else issued it. You have to remember that any XSS actually defeats all of that. That's very important. XSS attacks give a full access to your website, to the attacker. In term of operations, they can do on the behalf of your user because they can run arbitrary code within the same domain. Even same site policy won't save you in time of XSS. CSRFs are easier to patch in place, but easier to defend against. XSS, they are hard to find but when you have them, well, we are playing in good mood and that's why there are things like trusted types that we've seen in the course about XSS that enable to have a consistent protection throughout the site against XSS. Also, that's interesting part to not choose get request for a state changing operation. This actually by default, you don't have protection for CSRF and git operation. It's mostly on first operation and formulas. Well, if you have git requests, that can change the state like make a payment, send a message. You want to have the same protections against CSRF. Altogether, the two interesting parties are if your worth framework provide CSRF protection unit and implement a user-based interaction prediction. This can be a lot of things. This can be adding multiple clicks to do, to be able to perform something. This can be multi-factor authentication. This can be email validation for the most sensitive operation, like bank transfer but you don't want to single HTTP request would be enough to perform a high- privileged operation on your application. That's it for the video about CSRF. I invite you to follow the rest of this course where we'll talk about clickjacking and some resource integrity. It's actually one of my favorite courses in that learning track. Thanks so much for watching it, and have a great day.
