Cross-Site Scripting

[00:00:00]
>> Steve Kinney: So CSRF attacks are real, but they are between cookies, cores, headers, server side validations through some of the security headers, tokens, UCAN, there's not like a what do we do? The world is bad. I mean, it is, but it's now going with a series of techniques. The next one is, both simultaneously, possibly harder to pull off, but also way worse if it happens, and that is our good friend cross-site scripting.

[00:00:32]
With CSRF, it's coming from out the outside world and you didn't intend it and maybe it has some conjecturing. XSS, cross-site scripting is like someone jams some code into your page and now, as far as you can tell, this request is coming from you, right, or maybe it's purely client-side and they're just scraping credit card inputs out of the page and fetching it away.

[00:00:59]
It's not easy to pull off, but the chance of it making your day very bad is a lot higher. So let's kinda talk about how it works. There's a few different kinds, stored, as they put bad stuff in your database. On one hand, that's really bad, cuz everyone who loads that is affected by it.

[00:01:24]
On the other hand, pretty good, because you can just delete that stuff in your database. Reflected is interesting, because it means anytime you're pulling data in from a query param, or a header or something like that, and displaying it on the page. It means that they jam something into a query param or something like that that then injected code onto your page, right?

[00:01:47]
And DOM-based is you can put malicious data in there, and that will cause something. That one's a little trickier and a little more esoteric, so we're going to stick with stored and reflected. DOM-based is real, but it's a little weirder. And so the big difference is that cross-site scripting, they have injected code into your site versus cross-site request forgery where it's coming from the outside world.

[00:02:12]
Of course, the request forward during the day is just an HTTP request that you didn't want to come in. This is literally code executing out of your sight. And there are some very famous attacks, and let's talk about them. The kind of, maybe not the first, but the first super famous one was the Samy Worm on MySpace, where they used a certain post.

[00:02:38]
That if you saw it, it loaded code, and we'll talk about how it worked, cuz I think it's a good explanation of cross-site scripting. It injected some code onto the page. And as soon as you saw that, because this was a stored attack, your browser was affected and then you posted the same thing.

[00:02:54]
It did two things, it made you post, but most of all, Samy's is my hero. And it made you send him a friend request, right? As well, so we got fewer than we would expect today, but a lot, like 90,000 friend requests. But still, 2005, that's not bad.

[00:03:11]
In 20 hours, it's spread to over a million users, or something like that.
>> Steve Kinney: And so this was a screenshot that he posted right after it happened, where he had, yeah, no, they have 900, not 90. There's no comma there, 900,000 friend requests kinda sent. And effectively, it was not dissimilar in older versions of, I think Safari and Internet Explorer, cuz this is 2005, I'll remind you.

[00:03:43]
You could not only do what we did with the void, but you could also put JavaScript URLs as a CSS selector, right? Now, that's bad, totally. But MySpace, they're not, this isn't their first rodeo. That code doesn't work so much that the syntax highlighter in modern stuff is like, I don't even know what you're talking about there.

[00:04:10]
It was a little more nuanced than this and we'll see it in a second, but basically it allowed to put some JavaScript in the page with a background URL. But MySpace, they sanitized their inputs, right? They stripped out script tags, all sorts of stuff, right? So you could put an eval in there, but again, they were stripping this out.

[00:04:36]
No big deal, right? And so you could hide stuff like that in there as well, but it didn't strip out a new line which did compile. And this is when I was saying earlier that a lot of these attacks, the vectors are very common, but on a particular site and he's got a blog post about this.

[00:04:57]
But it isn't like he just did it and it worked, it was the human spent probably the better part of a few days crafting this attack, right? And through feedback of, I did this thing and I found out it blocked it in this way. And then I tried this other thing and it blocked it in that way.

[00:05:15]
And I tried this other thing and that's kind of the nature of some of these attacks, so it didn't strip that out. But then you got the problem of escaped quotes, right, because it did strip those. But now he could execute JavaScript, you could do string from character code, which would make a quote, right, cuz you're trying to basically build out JavaScript and inject it into the page.

[00:05:36]
So he gets that first little payload in with the JavaScript URL, and then starting to build out the rest. The full code is published. It doesn't work anymore, but the full code is published. Okay, cool, you're gonna strip out this out, then I'll use this other thing. And then again, they blocked innerHTML.

[00:05:54]
But now that he could get JavaScript in there, they didn't block INNE plus HTML, right? And again, you can see how the attack slowly builds up over time. And you can see the full source as well, and be able to kind of run through the entire thing. Another one was, again, a very similar thing is not dissimilar from what we saw with the SQL injection earlier, which is if you can break out of an attribute or some escape string, you can do a lot of stuff.

[00:06:26]
So in 2009, a Twitter worm basically found a way, hilariously, I think it's on the next slide. It happened twice in the same weekend in 2009, but hilariously, you tweet something normal like this, it made it a link. It's just a URL, it made it a link in the page.

[00:06:53]
But for some reason, for Twitter, who has at mentions of all things, the @ symbol broke their HTML parser, right? And it created an edge case where then you could put it onmouseover. And this is an error, where you just have to have jQuery available to you, because it was the year 2009.

[00:07:13]
So you got all the jQuery, you don't even have to write innerHTML anymore. You've got jQuery, it's allowed, right? And then you can see the hidden in the XSS attack. If you look at that, $status-update-form.submit, I guess it's not technically a cross-site request forgery, because the call is coming from inside the house, but it's very similar to what we saw earlier.

[00:07:38]
But the moment you hover over that link, you then execute that jQuery. So as you can imagine, people are posting you this thing and then everyone sees it and then they hover over it. It goes as well.