Elements of a CSRF Attack

[00:00:00]
>> Steve Kinney: This is theoretically the basis of what a CSRF attack can be, which is a post request gets sent. In this case, like this one's got a fairly destructive action, right? And all you have to do is trick a browser into doing this. And unlike cross-site scripting, which we'll see later, you don't need to inject any code.

[00:00:22]
You just need to trick the user into visiting something that you could fully own the site, right? And it doesn't have to be through JavaScript. Now, luckily, between the stuff we saw with cookies and some of the additional things we're gonna talk about next, you can protect yourself against, again, yeah there's always a chance that there's a tiny edge case.

[00:00:41]
But you can get to that 99% or possibly 100%, but you never truly know, kind of coverage area, through some techniques. But a lot of times, I think this is one of those ones where people assume that this isn't really a thing anymore, and I don't have to worry about it.

[00:00:59]
And maybe, right? But maybe not. So the way that it kind of works in a lot of cases, the GET request is just irresponsible, right? Your GET request should never change anything on the server. We all know that we either seen or been party to a time where we have done that, right?

[00:01:20]
And it's one of those ones where someone was, well, I had to do it like this for such and such reason, right? Or someone didn't know better, it's happened. The POST request takes a little bit more work, but I could fit an example on a slide, right? Which is you have a page where the display is not what you can actually do, opacity zero is probably even better cuz I think modern browsers might not load DOM elements that are fully hidden, but they will load ones that with an opacity of zero, which has a whole bunch of consequences.

[00:01:58]
I'll be curious to see in a few years if that's still true, but at the time of this recording, it is so kind of just either putting a form somewhere, either in plain sight, honestly, or with a passive zero, putting in the page, and then just using JavaScript to submit it, right?

[00:02:15]
And there's even like another nefarious thing called clickjacking, which we'll see later, where it's, you don't even need to do that. But that is effectively the fun, and because it's a legit request coming from that browser, right? Depending on how you have those cookie attributes set, that cookie will pass along and it will be them now.

[00:02:37]
So messed up when we alluded to some of the same site stuff that we talked a little earlier about can provide a level of protection, but then there's also ways to on your end, make sure that you don't. If for some reason, the cookie still comes through, for whatever reason, right?

[00:02:50]
Cuz even what I was saying with Google like and Chrome and Firefox and Safari, where cookies by default are set to Lax. I have seen people with old enough computers to know, right? I think Safari releases are tied to the version of Mac OS you have and there's an end of life to Mac OS updates.

[00:03:11]
I have seen people who still have that aluminum brush metal chrome. You know what I'm talking about? Brush metal Safari, from a really old version, old browsers exist, right? And depends on your audience that might still be a subset. And ideally you have metrics and locks and know what your usage is and whether or not you need to be fully aware, but like there are still ways that this can happen.

[00:03:33]
Or you can't use some of those same side things cause of the architecture of your app. And you have a whole bunch of different domains talking to each other and it's really hard. So, there are three ingredients to the recipe of a CSRF attack sometimes called sea-surf, which I don't know.

[00:03:47]
I don't know how I feel about it. I named an example app after it, but I haven't really fully committed to it, which is some kind of relevant action, right? Again, this is like the YouTube user account change. This is like a tweet. This is even the email that's, again, there can be creative ways.

[00:04:02]
Yeah, they can send it. Who's gonna send fake email? Yeah, apparently if they wanna harvest email addresses plus passwords, they will. You do need to be using some amount of cookie-based session handling cuz theoretically, other than hiding a form and submitting it, CSRF architects don't require any Javascript.

[00:04:17]
So they don't have to inject JavaScript on your page, they just need to call an HTTP request somehow, some way. There are ways to do with CSS, there are ways to do with images, there are ways to do with JavaScript. And then no unpredictable parameters. So that delete account, delete equals one.

[00:04:34]
There's nothing, there's no entropy in there, there's no randomness, there's nothing unpredictable. Once you've figure out the signature they attack, you're off to the races. Now, that third point there is doing a lot of heavy lifting because guess where the solution is hiding, and having unpredictable parameters, spoiler alert.

[00:04:51]
But those are the three pieces. So as long as we can take one of those things out, you're probably not gonna to be able to take relevant actions out of your web app. You can lock down those cookies, right? And you should, but you know, I think the one that we're gonna focus on is that last one there.

[00:05:07]
Cuz again, for most of these things, like even if cookies are protecting you, you should also still have multiple layers in case something fails you at some point. Cuz again, a lot of the security mistakes are mistakes. Not that you intentionally left a loophole. It doesn't really acquire JavaScript and we'll kind of see that at various points.

[00:05:21]
They don't need access to your site, right? They just need them to go visit some other site. You notice that browsers have been doing a lot more about showing you the lock and the name of the site in the browser bar. A lot of times they won't show you the full path, cuz a lot of times somebody would use a pass so long that it was like delicious.com/http://paypal.com.

[00:05:45]
Let's confirm your account, right? Or something, whereas if you were not paying attention, right? Or maybe not as computer savvy, you might think this is totally, it looks like the PayPal site or something along those lines. Lots of different ways that this can manifest as we saw, but it can happen.

[00:06:06]
So how does it work? The user needs to be logged in to the target, right? Cuz that's why they have a valid cookie. You're not stealing the cookie, you're just using it in a way that the user didn't intend. Then they do need to fall into your trap, right?

[00:06:19]
And like not a topic really for this course, but I think we're all well aware that a lot of it like phishing is a lot of his social engineering too. Many of the worst modern security exploits have also been like, I called up customer service and got to give them information they shouldn't or something along those lines.

[00:06:36]
But that's still what we're talking about with a lot of the tricks to try to pull out the information about the server, these are all kind of ways of gaining some amount of information, right? And then we do send some HTTP requests with their cookie from their browser to the app that is some way not protected and arguably doing an unauthorized action.