Cross Site Request Forgery - Computerphile

Key Takeaways

Cross-site request forgery uh CSRF is the third big web attack. I've talked about cross-sight scripting in the past. I've talked about SQL injection. This is number three and it's the lesserk known one. Web browsers are fairly trusting things. Um I've said this before, if you give them some code to run, uh they they don't cast a value judgment on it. They can't tell if it's malicious. They will just run it. Now this was this was kind of okay in the in the early days of the web when there wasn't online banking and things like that. You know the worst you could do is is put a comment somewhere. Um nowadays bit more complicated. The web runs on data being sent back and forth and that data can be encoded in a couple of ways. You can have what's called a get request and that's like if you if you look up if you're using this on desktop and you look up at the the you know browser address bar you'll see youtube.com/watch. it's the name of the page and then a question mark and then v equals a string of characters. That means that you're going to the watch page and then the rest of that gets stripped off and sent to the logic at YouTube which says oh we want this video to pull these details out the database. There's another way of doing that called post which is the kind of thing where you have a form with a button at the bottom of it and when you hit go then all that data gets bundled up and sent along with the request but not in the address bar. And traditionally that if you put it in the address bar, it's designed for fetching data. It's called a get. So that means that you can take this YouTube URL and copy and paste it to somewhere else. And just bundling the data up like when you click go on a form is called a post. And that's meant for writing things for what things that happen once. So that when you hit refresh or go back to the same page, it doesn't do the same thing twice. So, if you enter a comment, um it doesn't put all your comments details in the URL bar and you can't copy and paste that to a friend and they'll post the same comment. And that's that's reasonably good for the early days of the web, but since then it's got a bit more complicated. Let's say you have a form uh on your website uh for an online bank. So, let's design a really bad online bank form. Let's have send some money from your account to this account number and send this much. And then there's a go button. And let's say that as long as you're logged in, you know, as long as you've been through all the authentication checks and, you know, use that little chip and pin device that gives you a password to type in, you've got access to that form. You type in the account number. You type in how much you're transmitting. You select go. First of all, this won't use a get request. It won't appear up top like YouTube does. Uh it'll bundle it up as a post. It'll send the request and your bank will send back that it's done. But the trouble is that form is well almost public. You know how it's designed. So let's imagine you set up a fake web page somewhere else that has that form on it. And maybe, just maybe, you hide some of those details. So, they're already typed in. So, it already has your account number in it and say £1,000. And then when someone comes along and they want to uh put a comment on your website, so let's design uh a really malicious blog. Let's let's call it my awesome blog. And let's write some really inflammatory content that that people will love to comment on. And here is a comments box. But off here, off off screen where they can't see it or even completely invisible is a box that says account number pre-filled with your account number amount a,000. I've written a hundred £100 because apparently my my hand has lower ambitions than my brain does. And when you click that go button, it's not going to my awesome blog. It goes to the really badly designed online bank, which promptly says, "Oh, we've got a request here. don't know what all this blog nonsense is about, but look, we've got an account number. We've got some money. Transfer it because we've already been authorized because you're logged into your online bank in that other tab while you were bored. And well, great, the money is gone. And it gets worse than that because uh if you've noticed when you type a comment on YouTube and you click post, it doesn't load the whole page back like it used to in the early days of the web. Now it does it all in the background silently and just sends a thing back saying, "Yeah, that's fine. No worries." Well, that would work with this, too. You wouldn't even need to click the go button. It could just be that when I load up my site, my malicious awesome blog, it just creates that form in the background and sends off that request. There's a few things in browsers designed to stop you doing that, but there are ways around them. Now, that's obviously quite a big problem. Online banks are generally not designed that way unless they're designed incompetently. But a lot of web forums, a lot of smaller sites have problems like that. If you've ever designed something with a delete your account button, then frequently it just goes to something like slashdelete with maybe, you know, confirm true on it. And you assume that the only time that form will be visible is when the user is logged in and has clicked no, I really want to delete my account. I could copy that delete your account form and just put it in the background of my completely irrelevant web page somewhere else and you wouldn't even see that it had fired because it's all happened in the background using modern web technologies and you wouldn't notice. It would delete your account quietly in the background because that form that delete your account form or that transfer the money form hasn't checked where the request is coming from. There was something in in what's called HTTP, the hypertext transfer protocol, the the very basics of the web, designed to stop this. And it's called the referral header. And it means that when you click a link or submit a form, it includes a thing that says referer this site. So you know if the form request is coming from the actual online bank or the actual delete your request form and not some malicious site elsewhere. The trouble is, if you start checking for that, a lot of users start complaining because that referral header isn't always sent like it should. Maybe you've got an advert blocker or maybe you've got some kind of privacy tool that's blocking that as well. The way to get around that is a one-time key. Uh what the Americans called a nons and which the British definitely do not call a nons. Um the onetime key works by the form on your website generating a unique code. can be anything just a random string of characters each time you create the form and then storing that character and saying right anything that comes back anything that I see needs to have this token with it and this this code this token you've generated is in the form as well completely hidden invisible to the user is something that says token random string of characters I think I just wrote a number plate Um, this random string uh is meaningless, but what it represents is that this form that I just made and I just sent out the user is the one that's coming back. So, meanwhile, over on on my malicious awesome blog, I don't know what this token is. I can't possibly know what this token is because it changes per user and it changes every time the form is requested or at least every few minutes. And if you copy that form, if you take that token and try and use it five minutes later or 10 minutes later or on a form that's already been submitted or for a different person or for any one of these things, they'll look at that token and they'll go, "That's wrong. We're not having that." And suddenly cross- sight request forgery doesn't work anymore. And there are still theoretical attacks and and lucky flukes that could get past this, but in general, that solves it. So, if you're designing web forms for anything which which is permanent, anything like deleting an account, posting a comment, authorizing someone, or even transferring money, if you're not using this, this is a pretty big security hole. And if the sites you're using aren't using it, well, you never know what might happen when you go to some malicious blog somewhere out there. So, that's cross-sight request forgery. And it is it's the third attack. And everyone knows about XSS. If if you're a web developer, cross- sight scripting, XSS is the one you know about. SQL injection, database attacks are the one you know about. But this this one went under the radar for a long time, and there's still a lot of developers that don't know about it. So, if you're designing a site or using a site that has anything kind of permanent to it, have a look and see if a token's being sent because if it isn't, might be a bit of a security hole there. You start with a script tag and then everything stops. You've got a closing script tag down here. Nothing in this section will actually appear on the user screen. What you now let's say I type in Tom with a quote mark in it.