Thank you. Everyone. Is Canada Hill Master Instructor, A cyber. In this video, we're gonna talk about Web defense.
So just a quick pre assessment question here. Johnny's a security analyst, and he's wanting to basically fight a sequel Command that will help prevent against master data loss.
So which of the following commands that are listed here should he use?
Have you guessed answer? Be the limit Command. That is correct. So that one was kind of easy there if you knew anything about sequel commands.
So I mentioned the OSS top 10. So these air the ones from 2017 s, we've got injection attacks. That includes sequel injection command, HTML injection, broken authentication, sense of did exposure. And I'm not gonna read throughout, at least for you again. The slides will be available for download on. The resource is section of the course,
and we're gonna go through each one of these throughout this particular module.
So we talk about injection attacks. So what does that actually mean? Like what? What does some attacker doing? Well, they're taking untrusted data, so they're so if you're not basically if you don't have parameter for controls in place, if you don't have sanitizing of the user input if you don't have, uh you know, uh
the information that's coming through in some capacity, then basically, what that allows an attacker to do is put whatever they want it, like your user name or password field on your log in page of your website as an example. Or, if you have, like, a contact us stop a form that can use that as well.
So it's essentially untrusted data it's gonna be in. It needs to be interpreted, so it's gotta be in dated. That's interpreted. So, for example, like sequel. And as I mentioned the most, the three common types are gonna be sequel Injection command in html. Injection on against sequel injection Be them being the most prevalent
that you probably encounter throughout your normal day today. Stuff in the industry
so different types of sequel injection. As I mentioned, we're gonna focus on that primarily we've got union based airbase blind and also a stacked queries is what is called.
So you didn't base. This is going to use the union statement Now when we go through our lab a little later on, we're actually going to do a union statement will put one in. Just you could see what that looks like on we'll compare the difference between the output we get there compared to everything else we had gotten in the lab.
So the union statement essentially allows you to join together different select query. So, as an example, I might say, Oh, you know, let me get the user names from here. The passwords from here, the, you know, due dates of birth, the so security numbers. And I can join all that into basically one
sequel query as part of my attack. And I can hopefully get all this all the information out of the database
we've got air based. The goal here is to try to get a response back. That gives us a lot more information about the database itself. So if we have improper air handling in our responses than what an attacker can do, they can send a query to the database that they know is gonna, you know, generate an heir.
And the goal there is to get back information about, like to tape the table names, eso You know, I might get an air back that says, Oh, you know that command wasn't recognized. That syntax wasn't recognized in, you know, table user name and table password or something like that right there. That's a very simplistic example. But
you get the general idea.
It's giving the attacker information we don't want them to have. So we don't want them to know what table the table names actually are in the database. We don't want them to know how many. You know, columns or tables are in the database, right? So all these things here, That's why we want to limit the amount of information they're getting back in air that's generated.
We've got blind sequel injection attacks. So this is where the attacker, in most cases, not gonna get any type of air messages back from the database. And now there is a way for them to tell, like what's whether an answer might be yes or no type of thing. Eso like time based, based off, You know, the amount of time it takes back to get their message,
they may tell the attacker.
Okay, well, that's a yes, that that you know that table exists or that's a no, that that you know is not relevant.
Step queries. As I mentioned, basically, these were designed to terminate the original query. There's an example of on the screen there that were really hitting stuff at a high level in this module. We're not gonna dive into anything. So if you're a developer out there, if you saw for developer out there, this is not necessarily the module for you. There's still good march up to get a high level overview, but we're not gonna jump into the code itself
and show you how to secure it better.
So prevalence while sequel injection or, you know, injection attacks in general are actually pretty prevalent, which is why Attackers used them so much. A za mentioned sequel injection held up in some cases command injections. You know, the OS be operating system commands,
uh, expression languages. There's some vulnerabilities and XML par sir's SMTP headers,
etcetera, etcetera. So there's a lot of different ways that an attacker can go in and do stuff again. I mentioned that sequel injection is probably the most common way for an attacker to do it.
So how do we check for these types of vulnerabilities? Well, of course, if we realize that our systems are not. Our Web application is not validating input. So not validating user input. That's, you know, probably number one way. Also dynamic worries that don't have context We're escaping and then structured or hostile data in our queries.
So the impact Well, what's the impact, right? Well, we obviously know it's probably data loss, but also data corruption. An attacker might be able to get privileged access to the database and corrupt the data in there that may also be ableto figure out a way to lock us out or or deny us access to the data in the data base. Maybe they encrypted or something like that
and that also, you know, as part of the data loss aspect,
disclosing that data to unauthorized parties.
So how do we prevent it? What? What's kind of prevention or mitigation steps? Number one method is gonna be input validation and sanitizing user input, and then also parameter eyes queries. And then another thing we can do during the development process is source code review, right. So we could do static and dynamic analysis to kind of see like is is there an option here
where someone can do a sequel, injection attack
and if so, is it a difficult thing to do? Because sometimes it may be a vulnerability, but not necessarily one that's relevant to our organization, so just kind of keep that in mind.