Other Types of Injection Attacks

[00:00:00]
>> Steve: Like I said before, we kinda saw this slide a second ago. But the other one that were not covered here is this idea of man-in-the-middle attacks. This is, again, someone in the middle sniffing the network traffic. Luckily, this is easy, and we'll talk about it. Could you get a cert from Let's Encrypt and localhost?

[00:00:17]
Yeah, but ideally, most of your production environments, right, if you use Vercel or whatever on a small app, you have HTTPS, unless you somehow find a way to opt out of it. If you do not see it, most browsers get really mean about not having it. This is luckily either, again, if I had a big company, had an infrastructure team and a security team, yeah, you probably have your own servers.

[00:00:42]
A smaller thing, I would say that rolling and stuff yourself, you can do it, maybe you shouldn't, right? But if you choose, that's great. I will say, just as an aside, there are apps out there. There's one called Charles that runs on Mac OS and iOS, which is super cool, where you can man-in-the-middle yourself, right?

[00:01:03]
You're like, why would I want to man-in-the-middle myself? You know how I was saying the browser's great cuz you can sniff all the network traffic? You could theoretically install one of these apps and then open up whatever iOS app or Android app and expose the hidden APIs, right?

[00:01:21]
So even going like, my APIs are hidden cuz I work on a native app, they're not, right? You're not off the hook just cuz you have a mobile app. Arguably, because the web is such a big platform, you are better protected on the web, right? You can sniff traffic and man-in-the-middle.

[00:01:37]
It's the same idea of this privilege escalation. Maybe it's for other nefarious purposes or your own research, ideally, where you could go look at your own and like, am I being mature here or not? But also, if you're just trying to figure out cheap United flights, you could theoretically, I don't know.

[00:01:54]
I'm not finishing this story. But it's a useful tool. But some of these techniques are useful. Okay, so the cookie attributes that we saw before, HTTPOnly, again, I would say your cookie should be HTTPOnly, unless you have a real good reason not to. And you might have a real good reason not to.

[00:02:11]
For instance, maybe you have some single-page application, right, where you do need access to that token from JavaScript. Yeah, well, that's why we have multiple ways of solving a lot of these issues, right? And there are a ton of different things you can do. But you know you need it if you need it, but also maybe spend the time to figure out how to just make it.

[00:02:32]
Cuz if you can access it from JavaScript, anyone who can get JavaScript in there, too, right, which we'll see later, can do it as well. So try your hardest. Secure, I don't wanna hear this one, yes, use HTTPS. And then SameSite, we will talk about momentarily. But this is basically saying that, hey, don't send the cookie unless the request comes from one of my sites.

[00:02:58]
And we will talk about this. I think it's important. But I just kinda wanna spoil it in advance a little bit, which is there used to be SameSite none, which was the default. Then there was a strict, which is you hate your users. Cuz it means that if they ever click on a link, they're coming from somewhere else and they're logged out, right?

[00:03:15]
Can you imagine someone sends you a dank meme and you're not logged in to Facebook or X or Instagram? You are logged in, but because you didn't click on a link in there, you're logged out again, right? That stinks. And then there's Lax, which is kinda in the middle.

[00:03:29]
It used to be that if you didn't set a SameSite one, and we'll discuss it again in a second, but you would set it to none. In this case now, Chrome, all the different browsers as of two years ago or so will default to Lax, which broke a lot of stuff, but in the name of better security for everyone.

[00:03:49]
So because people made this mistake a lot, cuz we'll see all the different ways you can also leak cookies later as well. But on the SameSite attribute, unfortunately because the Internet is weird, as I said in the opening preamble here, site and origin are not the same thing, right?

[00:04:07]
And we'll have slides later on as well, but origin, remember, is that domain port and protocol. A site is the TLD, so com, net, whatever, and one level up. So subdomains are fair game, right, in a lot of those, right? There are exceptions, which is you can register yourself onto the public suffix list, right?

[00:04:32]
So cuz github.io, everyone's got a subdomain before that, right? So that actually counts as a TLD. Probably, it's public. There's literally on the slides that's similar links to it. Let's click and see what happens. Yeah, the public suffix list, I just gotta bring this tab over, is an open source list where people can go ahead and add themselves to it and the browsers will respect it.

[00:04:55]
So I guess most popular services like github.io. I'm gonna guess vercel.app. Anything where you can get a subdomain.whatever.tld. However, you're like, let me use some funny new thing that might not be on here. You have a risk that they're not on the list, and then you could leak cookies accidentally.

[00:05:15]
But generally speaking, there are exceptions to this case as well. All right, so we talked about injection attacks and the definition of those. So in conclusion, the injection attacks that we kinda saw with the example earlier. The SQL injection, there are a few other ones as well. And I mentioned them while I was riffing.

[00:05:36]
Command injection, if you find yourself shelling out, calling something in Bash as part of your business logic, well, you have a new attack surface, right? The various escape characters, there are libraries, it's about sanitizing your input. You can either choose to do it yourself, you can use a library.

[00:05:57]
It's tricky. I would say use the library 99% of the time, unless it's really important and you know what you're doing because sometimes no one's read the entire React code base, right? No one's read the entire Express code base. You know what I mean? Sometimes knowing exactly how the code works and being able to run your own test suite against it is also important.

[00:06:20]
But 99% of the time, use the library. So command injection, again, they just escape, the shell. And this is anytime you find yourself calling, either a child process or any, depending on your programming language. I think Ruby and Python make it shockingly easy to call shell commands. I think backticks in Ruby is a shell command instead of a quote, right?

[00:06:40]
And so that kinda stuff to make sure that you're not doing it. Command detection as well, yeah. Here, we're gonna exec a guarantee this is ls. Someone could theoretically put a semicolon at the end, an rm -rf you, right? This is an example, obviously, that fits on a slide, but the idea is exactly as we saw in the SQL injection.

[00:07:01]
There are other forms of injection attacks depending on the various things that you're doing. So every time I see somebody use Bash or something, especially deployments, but also insecure, it's like you're what? No, you don't need to. If you truly need to, if there's not even a node built in if you're reading from the file system like that ls example, there's a reader, right?

[00:07:25]
Use that, right, if you truly need to. And I have things in my code base where I do shell. It's mostly scripts for generating types. I'm not super worried about it and they don't run in production. Then you've got execFile where you can do something, or sanitize the allowlist.

[00:07:44]
But every time you find yourself calling out to Bash, any time you find yourself using data that you're getting in as code. Understand that there's an inherent risk there and you're putting yourself in the path of sadness. The other one that I'm not gonna talk about cuz it's kind of unique is this idea of file upload vulnerabilities.

[00:08:04]
I run a video processing site, and it's the same thing, you don't check. Let's say it's like, upload your image and we resize it for you. You know what you need to do? Make sure it's an image. [LAUGH] You know what I mean? A file upload vulnerability. Someone uploads either a Windows executable.

[00:08:23]
They figure out you're running on a Windows system, or some other file, or some known bad payload that they know that FFmpeg is guilty towards, right? And then remote code execution is like, yeah, you decided to use eval. [LAUGH] And again, now you opened yourself up to bad things that can happen in JavaScript, right?

[00:08:43]
It's different flavors for the same thing. But again, I could say, and I did say don't do these things, but sometimes you have to, right, depending on what you're doing, right? Sometimes if you are running a video processing site, you're gonna have to take file uploads and process them.

[00:08:56]
If there are certain things that you need to shell out for, do it, right? Or you need to compile code and evaluate it. Sometimes these things exist cuz they occasionally need to happen. But again, know that these are the surface areas for sadness, right? And that in a lot of cases when we look at cross-site scripting later, there are known repositories of just bad payloads.

[00:09:19]
And running those through your test suite to make sure they do the thing you think they're gonna do is pretty important. So yeah, we have remote code execution. Don't use eval, function, exec. If you're doing stuff with a DOM, stuff like DOMPurify, which we'll kinda talk about. Or sandboxing stuff, putting in a Docker container, depending on what you're doing, all of those things apply.

[00:09:43]
They're a little bit outside of the web stuff, but generally speaking, right, the same ideas. Web security is just theoretically a subset of security. General good security practices take effect.