Introducing Cross-Site Request Forgery (CSRF)

[00:00:00]
>> Mike North: We're moving on from cross-site scripting to the second most prevalent vulnerability in web applications and that is CSRF, which stands for cross site request forgery. And what this takes advantage of, what this exploits, is the fact that, by default, cookies and basic authentication credentials, which look like these, right?

[00:00:23]
If you've ever seen this before, this is basic authentication, where your browser's asking for your username and password. They are sent along with each request our user makes by default, unless you sort of opt out. And so if we, for example, currently in this app right now, we have a pretty horrifying problem, where we can actually make a get request that will transfer our funds from one account to another.

[00:00:48]
So imagine I've got a little image tag like this and I put that image tag into an html email and I send it to a customer. If they happen to be logged in, if their cookie works, they'll make a request to this. Their credentials will be passed along, and by the time that request finishes, they will have basically asked the bank to transfer funds to some other account.

[00:01:12]
So this is an obviously good reason to align with RESTful HTTP verb usage, right? We don't want get requests that mutate data. But we're not safe even if we only allow post and put requests. Because now I just have to take a different approach, where I would use some social engineering to basically call up and say, hey, this is the IT department and we're about to roll out a new update.

[00:01:43]
I just wanted you, can you click on this link. And I'll send it to you in an email in a second, and just please verify that it works. And then have code that looks like this in that landing page that I control, where basically we have a hidden form and with JavaScript we can programmatically tell that form to submit.

[00:02:00]
So this will make a post request happen. By default, we won't be able to see what happens, right? This will be what is called an opaque request. But we don't need to. We can just try to hit a bunch of people with this and whatever happens, happens. I mean, we'll know what happens if we control the other account.

[00:02:16]
We'll see money coming into it. So we just need to basically attempt to run this on a bunch of users who may currently have cookies that can be used as credentials. And now, that the backend will say you are an authorized user, please go ahead. This takes advantage of the fact that I can run code on any domain that'll potentially hit this across origins, across sites.