7 hours 6 minutes
Hey, everyone, welcome back to the course. So in this video, where to go over a brief introduction to sequel injection attacks. And in a later video, I'll actually show you a demonstration of a sequel injection attacks. So we'll talk about in this video. What a sequel injection is. So basically, what is a sequel? Injection attack? We'll talk about some of the different types of sequel injection attacks, and then we'll talk about
some countermeasures you can do to help protect against
sequel injection attacks.
This is a type of thing that if you do take the CH exam, you'll just wanna be very mindful of various Web attacks. So, in particular, sequel injection attacks. So you wanna understand
what it is
and ways to defend against it. And that's pretty much all I can say without giving away stuff on the on the actual exam itself. But just you wanna know Web attacks? You wanna know Web application attacks specifically. You wanna really understand? Command injection is equal injection attacks.
All right, So what is a sequel? Injection attack? You can read for yourself on this slide here, but essentially a sequel. Injection attack is a new attack that weaken do because the input on may be a form or a log in box or communication form on on the site, whatever it is
is not validating the input. So what that might allow us to do is pass commands
through the Web app back to the back end database and then get
get queried information back
that gives us sensitive information right so way. Send these queries in. We put in our sequel Injection Attack we. It's basically a query sequel query, and we put that information in its not validated. And so then that command gets passed back through the back end database and it pulls the information that we're looking for to us.
So what are some of the different types of sequel injection attacks? So we've got Airbase sequel injection attacks, which is basically
where the attacker is trying to look at the air messages. So based off the response, they'll be able to determine
uh, information about the database or they'll be able to gather information from that database.
And then we have blind sequel injection attacks. Essentially, these ones are where the attacker is. They're not able to see actual data from the database, but based off how the response looks, they're able to determine. Is that yes. Is it a no? Is there specific information in the database? How many tables doesn't have?
So it gives us some general information about the database to perform further attacks.
So let's talk about each one of these a little bit. So with Airbase sequel injection, this is where we could do things like union, uh, sequel injection attacks. So, for example, were combining different sequel queries into one. And the goal here is to try to get that data back from the database.
We have tautology, which is basically where the Attackers injecting statement. That's always true so that no matter what the query, once it once it goes through and his value basically,
once the query goes it says, Okay, well, this thing is not true. But then this thing is right. So there's always some truth to that query. So no matter what it's going to say, Oh, yes, that's true. And then it'll, uh, potentially
give us that information from the database.
We have system stored procedures. Basically, the attacker here is exploiting the story procedures on the database
we have end of lying comments. So this is where the Attackers injecting code into a specific field.
And then basically any code that comes after that code that's been injected by the attacker is nullified through the use of what's called end of line comments.
And then finally, we have a legally or logically incorrect queries. So basically, this is where the attacker is in injecting incorrect request eso things like parameters or data types or names of tables to try to get back that air message that says no, that that table doesn't exist. But this one does right
or that doesn't exist in
this overarching table or this thing doesn't exist. So basically just trying to get information from that air message of what really
what the database really looks like.
We then have blind sequel injection attacks. So as I mentioned thes air, things like maybe using a time delay to where the Attackers gonna wait for the response
and essentially they're gonna get that yes or no response back from the database or a bully and exploitation, which is where multiple valid statements that
are either true or false or supplied to the http requests in the parameter there and then, by comparing the responses between both of those theater hacker can then figure out. Is the injection successful or not?
So what are some countermeasures that we could do to to kind of circumvent sequel injection attacks? So number one limiting the length of user input that could help eliminate the issue of a long sequel, Query being run,
having custom air messages that are not verbose. So we're not revealing information about the database in their messages. Monitoring our network traffic,
disabling certain specific commands. So setting specific parameters in place, isolating or segmenting our servers.
Monitoring or monitoring or disabling our post command. So limiting what an attacker can do, so can they actually do that? Http post requests
using concepts like least privilege. So if someone is able to access the database, they're only able to access minimum information and not getting the entire keys to the kingdom using things like type safe variable. So making sure that certain parameters that are used in a sequel, query or at least a militia sequel query those cannot be used
and also validating that user input. Right? So making sure that this is a
an authorized type of command for accessing the database.
So quick, Quick question here. All the following examples of airbase sequel injection Accept is that union tautology or time delay?
So if you recall the blind sequel injection attack is where we talked about the attacker. Isn't gonna, uh, see the data in the database. They're just gonna understand a response to what they've been doing. So in that example, Time DeLay is the correct answer here, along with Boolean exploitation.
So in this video, we just talked about what sequel injection is again. We we just went at a very, very high level, really. Just focus on the fact that it's not. We're not validating input from the user, whether that's a legitimate user or an attacker. And so because of that, they're able to access or potentially access data in the back end database.
We also talked about some of the different types of sequel injection as well some of the countermeasures
that we can do to protect against the attacks again. I'll show you an example of what that looks like in a later video