Loading
Current section: Cross-Site Request Forgery 4 exercises
lesson

Intro to CSRF

Transcript

00:00 so check this out i've got this note and i love it so much is my favorite note also i got this email from somebody who said that all i have to do is click on this button and i will get a free ipad i'm so jazzed about this so i'm going to click on this and get a free ipad

00:15 wait what what just happened where did my note go what ah what happened to my note oh no i just fell victim to a cross-site request forgery attack is so sad and it's so simple so what happened is somebody made a bad site

00:35 and sent me a link to it and had a form that has an action and that has a action pointing to my other site my local host 4000 where we're hosting this right now and then we've got our button and instead of saying you're about to delete your favorite note it said

00:54 get a free ipad and they don't care what it says they just care that they exploited this vulnerability that we currently have on our site in our forms there are various mechanisms for sidestepping this vulnerability one of them involves the way that you configure cookies with your authentication and stuff

01:12 but even then it's a really good idea to sidestep this vulnerability specifically and that's what we're going to do in this exercise so the idea is typically not to just delete notes but actually to like steal people's money and so like if you've got a bank then you could transfer funds from one account to

01:31 another be really really awful and say click here to win a free ipad and that totally legitly does happen sometimes so the protection against this is you simply create a special token that you store in the user's cookie and then you also render that in your

01:49 form and this is randomly generated every time the user lands on the page they get a new one and so when they submit the form that token that's in their cookie has to match the token that was submitted in the form otherwise you won't proceed that's a basic idea and because it's randomly generated every

02:06 time it's impossible for an attacker to be able to provide that in the form that they give your users because they have no idea what the token is for the users so that's yeah it's a pretty simple protection but it is very effective now this actually is a little bit

02:24 similar to what we're doing with our honeypot that we already implemented because our honeypot has an encrypted value for the valid from input field and so you do actually get this protection but the reason that we're going to implement csrf as well in addition to the honeypot is because csrf

02:43 is explicitly specifically designed to protect against this type of an attack whereas honeypot is designed to protect against a different type of attack and just because it happens to protect against both the the honeypot happens to protect against both that is not necessarily always going to be the case things can change in the implementation

03:03 as the honeypot implementation strives to fight against that particular vulnerability so it is a good idea to have this specific protection against csrf because it's a pretty serious vulnerability that apps can have so with that said we're going to use Remix Utils for this and we've got this

03:22 cookie that we're going to be creating we're we're not going to go too deep into cookies in this workshop we'll get to that when we talk about authentication but we have a utility from Remix that we're going to be using the create cookie utility that makes it really easy to manage these utilities or these cookies and our csrf utility

03:41 from Remix Utils takes that as an input so it manages all of it for us we just need to configure it a bit and we'll be doing some of that ourselves we'll especially be doing some stuff with the secrets you don't want to commit your secret like this so we'll we'll be doing that as part of the exercise

03:59 and then in your root loader you're going to use this api to get the token as well as the cookie header so you can set that cookie in the user's browser and pass that token for your forms and then in your root component you're going to wrap your entire app or

04:17 the parts of your app you care about in this authenticity token provider so that you can provide that token to all of the authenticity token inputs so that they know what what token to render as part of the forms that you're rendering and once you've done that then on the action of those forms you can do

04:36 this validation to make sure that the token that was supplied in the form is the same as the one that's in the cookie and then that no tampering has happened with that as well and if it doesn't exist in the form then it's probably somebody was trying to get you to transfer a bunch of money to Rick Astley or something

04:54 so that's the idea of what we're going to be doing in this exercise there's just a couple steps i hope you have an awesome time protecting your users from a really terrible fate so good luck and have a good time