Finding XSS Exploits

[00:00:00]
>> Steve Kinney: If you want to, you can play around. And there is an intentionally broken example, we can kill that Socialite app too. We do npm start and take a few minutes to play around with it, but we can go to, it's under xss, appropriately named. We've got unsanitized inputs, also you can see I've got this query param for Light and Dark mode.

[00:00:28]
That seems cool, who doesn't like Light and Dark mode hidden in a query param that definitely renders it on the page? And you've got this box where you can just type in anything you want and post it in the comments. What kind of trouble can you get yourself into?

[00:00:44]
Let's find out.
>> Steve Kinney: All right, this is a page with no protection. So,
>> Steve Kinney: It's everything bad you can do to yourself here. There's two ways to solve for this. Sanitize your inputs, right, which that was the one piece of advice we all actually listened to. And most of the time, should you use almost any framework, you almost have to opt out of sanitization, you know what I mean?

[00:01:16]
React in particular, it's underscore, underscore dangerouslySetInnerHTML, or something like that. If you find yourself doing that, it's time to ask yourself some questions, right? There are libraries, there's one called DOMPurify, which is pretty battle-tested. It can run in both the browser and on node. And it needs JS DOM, but I think it's probably the one that most of these things under the hood tend to use, right, 13,000 stars.

[00:01:48]
Could we do a whole hour of getting around filters? Sure, but ideally, if we got around a filter, it ought to be patched. And that would all be worthless within minutes, right? So let's talk about sanitization, use a library, you can write a simple sanitization function. Honestly, you get pretty far stripping out the angle brackets and replacing them, but use a library.

[00:02:16]
But if you're using a framework like React, like Svelt, like Vue, or anything like that, you will get this unless you choose not to get it. Server-side, there's, yeah, again, a ton of different options. Even if you use a templating language, like Handlebars or EJS, most things are going to try to save you from yourself.

[00:02:34]
Honestly, creating a few pages, the quaint little store has a bunch of vulnerabilities, and as well if you want to go looking for that, both reflected and stored that you can play around with, too. But generally speaking, most frameworks will handle the sanitization part fairly easy. So we'll look at some of the attacks, and then we'll look at, again, these second-layer defenses.

[00:02:58]
Because, yeah, even MySpace had sanitization, right? It was just somebody found a loophole that was, yes, incredibly novel and clever, right, and you've also got a shp feature. So having both a good, robust set of things and then also being able to kind of apply, I'll spoil it for you, a Content Security Policy to also protect you in case that fails is, again, one of those things that's probably not enough to save you.

[00:03:31]
Two of them together gives you pretty good coverage. So yeah, you can put all sorts of terrible things in here. You can do everyone's favorite, let's put it back on Light mode because I didn't think about it, checks go in the input.
>> Steve Kinney: I'm gonna regret this, I'm gonna have to clear the database, the most famous thing that we're all told to do.

[00:04:02]
Now when it loads in the database, that's executed forever, right?
>> Steve Kinney: Npm run clean, cool. The other one to show you kind of what a reflected attack looks like is where you would say, we got this Light and this Dark mode and it's putting the content in the page somewhere.

[00:04:23]
Yes, it's a contrived example because sometimes when you have this many example apps, you start running out of ideas. So we're gonna do a theme, and here we're gonna do,
>> Steve Kinney: We'll do the same idea of,
>> Steve Kinney: And ideally, with any kinda sanitization, all this stuff ought to be a moving target.

[00:04:46]
The reflected one you can see, as soon as I don't have that query param, the attack is effectively gone. So a lot of the reflected ones, both are weird cuz they're not in your database. They usually evolve in somebody finding the exploit and sending somebody else a link, right?

[00:05:01]
The stored ones are dangerous because anyone just needs to go visit the page. But at the very least, they're in your database, and you have control over getting rid of them. Theoretically, you have control over getting rid of them from the query params, too, but you might not even know, right?

[00:05:15]
You can do stuff, and you should do stuff, where if you have a different team working in the backend of, also, yes, you should filter out. But also, maybe you're running checks on the database occasionally and through the logs to check for weird stuff that you see happening.

[00:05:29]
But the vectors, and again, there are all sorts of playgrounds and exercises, but as a practitioner just trying to defend myself from it, ideally, anything we found today should be patched in the sanitizer or else we're bad people. So we won't kind of over-rotate on like, how do we really get in there and stick it to them, right?

[00:05:49]
We're trying to be like, how do we not end up in a newspaper, right? So with that, again, sanitization, DOMPurify, any templating language that you use or almost any framework. Even if you just wanna use Web there's lit-html, which is a super-lightweight templating language. That's got the protections in there, use anything, you already use something, all right?

[00:06:14]
Unless you are just really writing a PHP app from the 90s, there's something in place there. Use that, do not write your own. But let's then talk about that second-layer defense as well.