Cross-Site Request Forgery Case Studies

[00:00:00]
>> Steve Kinney: There was a theme in the beginning which is like taking over someone's session, right? That's bad, because once you can take someone's session, you can be them. And that's obviously a compelling target, but like, you protect those cookies, you put a bunch of safeguards in your business logic, you sanitize your queries.

[00:00:20]
You're getting to the point where you're getting, obviously there's, again, all security vulnerabilities are not the obvious thing, they are some tiny, little edge case, and we certainly didn't get to 100%. But what I think is important to do is at least call out that there are still more ways that your life can be hard.

[00:00:39]
And this one is, it's like one of those ones where I think the danger is that, kind of on that theme I just said, where it's like, yes, there are a lot of tools and safeguards in place that protect you. But you're not protected simultaneously, right? There are still avenues where this works.

[00:01:00]
And so this is called cross-site request forgery. You're not trying to be the person, you are trying to trick the person's browser into doing something that they didn't intend on doing, right? So you'd at no point get their token, you don't even technically get the information from a request, right?

[00:01:21]
But you are effectively seeking to trick their browser into doing something, right? And they legitimately have a cookie that says that they are them, right? And so if you are able to trick them into doing something, yes, you didn't become them, you didn't steal their cookie, but you could theoretically get some benefit.

[00:01:44]
And so, for this, and when we talk about cross-site scripting, which is a different form of an attack, there is prior art. So for instance, in 2010 there was a Twitter worm, and a worm is basically a attack that then spreads itself, basically. In the case studies in this course, did I include every Twitter attack?

[00:02:09]
No, because after a certain point where it was getting hard to name them all. So this is a CSR worm, where Twitter used to have an API, right? Twitter.com/share/update, and then a query param with your message, right? And so basically, by calling a GET request to that URL, you would post a message.

[00:02:33]
You can put GET requests lots of places, every image is a get request. Right, just clicking on a link is a get request. You can call it a fetch without even worrying about, of course, you can put a background CSS class that calls a GET request, right? And so I won't tell you the details of what this one posts, because it's not appropriate for this audience.

[00:03:00]
But basically, by seeing the link and then hovering over it, you too would tweet the link. And this will be a theme that we'll see of one of the easiest ways you could still be vulnerable to CSRF attacks, is by just sheerly breaking the principles of HTTP verbs, right?

[00:03:22]
GET should always be idempotent, which it means it shouldn't change state. You might get something back, but it shouldn't change anything on the server, right? And this violates that and creates a security hole as we go along. Netflix had, again, a similar idea with a GET request, where you could just do this JSON?AddToQueue?

[00:03:44]
And now if you had at any point visited a page with that image, the image wouldn't load, cuz that's not an image, but the GET request is gonna be sent, right? Which means all of a sudden you had brand-new DVDs in your queue, and like yeah, I guess that's not like a life-changing attack, it depends on what the DVDs are, doesn't it?

[00:04:09]
And depends on who's looking at your cue next, it could make for a bad day. In 2008 there was this paper that came out that really kind of talked about about the breadth of these. And they, for most of these, they had disclosed them before they put them out, but there were some bad ones in there.

[00:04:28]
So this is kind of another way of just data exfiltration, which is New York Times had this form on every article called email this, that made a post request and sent out an email, right? But the thing about CSRF attacks, it's like send and forget. You don't get the response back.

[00:04:45]
So what they would do, is they would cause your browser to send a post request with basically you emailing them the article, which at least your email address was. They could put on spam lists and build up nice, ugly, listen, they could sell, and stuff along those lines.

[00:05:01]
Right, and it was just a wide open, like a tactic could just collect. And if technically using both the site as it was intended to be used and tricking your browser into doing it, and we'll see how to do it in a second, for nefarious purposes. And kinda like, one of those things, they found it in this research paper and they just closed it, but who knows how long it was happening before then, right?

[00:05:23]
This is where we get to that logging and stuff along those lines. If you had logs and you had some way to at least check to see, hey, it's weird that 10,000 articles this month all got sent to the same address, right? This is where that thinking about the vulnerabilities, you're not gonna catch on that code review.

[00:05:39]
You're not gonna even catch that probably in a scan maybe. Maybe now you would, but back then you wouldn't have, right? It comes of like thinking of, if I were a bad person, not that I am, occasionally, what would I do and how would I exploit this? In that same article, they found this fun one, where you could open additional accounts on behalf of the user or transfer funds from one user's account to another one.

[00:06:06]
Now this one again, we don't know if it ever got exploited, right? Because researchers found it, but we don't know if it didn't get exploited either. And it's one of those things where some of these things just in the wild, in real use cases. YouTube in 2008, it's the same study, had one we could basically do almost every action a YouTube user could do at that time.

[00:06:27]
Add stuff onto playlists, like, all sorts of stuff like that, right? And again, it was legit user sessions in browsers doing things that neither the site or the people whose browser is expected to do, right? And as recently as 2020, there was one that allowed account takeovers through third party applications that could then trigger a password reset for TikTok and allow someone to fully take over the account.

[00:07:00]
Cuz again, that's a legit request, but the end result is the change password. Now, again, well, and then when I go over the kind of definition of a CSRF, but I'll say it now, it's fire and forget, right? Cuz you're taking their browser and making it do something, you don't get the response back.

[00:07:14]
But if one had a bunch of emails from any kind of leaked data set, even that New York Times one, and one was changing all the passwords to the same thing. Yeah, you gotta do some brute force work to put two and two together, but on a large enough data set, right, you will do it as well.