Hey, guys, welcome back to another episode on How to Hack, so we'll be continuing from the previous
tutorial on Web.
SWEPCO is a vulnerable Web application system and we actually stop at lesson number four.
So look, move on into lesson number five of SQL injection intro.
So go in and click on number five.
All right.
Over here we have what we call data control language.
So it is used to create privileges to allow users to access and manipulate different parts of the database.
Of course, over here we have SQL injection that could help us do, for example, granting of user accesses
to different parts of the database, revoking certain privileges of the user using the revoke command.
All right.
So, of course, over here we have an example of grand create table to a specific operator.
So this allows the operator to create tables inside the database system.
And, of course, here what we're going to do as an exercise to grand to use a group, an authorized
user, the right to alter tables.
So there is such an instruction it allow us to do so.
So over here we have what we call grand alter table to unauthorized users are going to paste it here.
So what we do is we are granting the right to privilege to alter tables in site de database system and
we are providing this authority to an authorized user.
So go ahead and click submit and we would have congratulations.
All right.
Congratulations.
We have successfully completed the assignment.
OK, so this is granting of the privileges to users to different parts of the database or to different
commands, issuance of commands.
So going to lesson number six.
So now we have understood about what are some fundamental structured query language instructions.
We can now move on to Ezekial injection.
OK, and this is what we are trying to do here as part of the tutorial is how can we bypass the boolean
operators, the logic of the database system and try to gain access.
All right.
Into the database pool of specific records, pull out the entire table of information and so on when
this happens, when input on not sanitized.
So allowing hackers to bypass the original intention of those applications that are used for input forms
that are used to do searching authentication.
So we have examples of SQL injection over here.
So we have the skill query to retrieve user information from the database.
Okay, so this is how I'll write.
A Web application server would call the database to retrieve information so we have select or from users
where a name equal.
So this will allow them to enter, for example, the user name and then after which the user name is
inserted from the browser into the Web application server and into the database to retrieve those records.
And for example, over here we have the variable username.
Holst's input from the client injects it into the query.
So we have select from users where a name is specifically over here.
So, for example.
All right.
So this is a really a wonderful instruction and demonstration of how it looks like, OK, so if we enter,
for example, Smith.
All right.
To actually help us fill in the information here and we can see select all from users when name is equal
to Smith.
So immediately we'll be able to pool information for this particular role and over here.
OK, so what the hackers can do is they can perform further information, attack into the input form.
So here, for example, we have Smith and we have a single quote.
So this ends the instruction here.
And what happens is we can enter or fill by single code one, equal single code one.
So this ends the instruction.
OK, so over here, select all from users when name is equal to Smith or one is equal to one.
So what does this mean?
All right.
So this will return all entries from the user's table.
Why?
Because or want equal one will always be true.
And if it is always true, it means that we will always get a result back coming in from the system.
OK, so over here, like once again, OK, we have a second one, right.
Smith All right.
Or one equal one followed by semicolon and double double dash.
All right.
So what this means is that we will actually also help return us all forms of entries from the user's
table and the second the last one over here to put one Smith.
And we end the school query and we open up a new query drawer table uses.
OK, so this would delete away all those user database.
All right.
All the users table.
And finally, we have truncate or det lock followed by double dash again and again, the purpose of
the double dashes to command every other query instructions that come off.
All right, the semicolon.
All right, so that's the whole idea of double dash.
OK, so this again, help us change multiple SQL commands and deletes the user's table, as well as
entries from all the lock.
OK, so now that is go ahead and move on to lesson number seven.
OK, so consequences of SQL injection.
All right.
A sequel injection.
Once it manages to bypass the intended use of these SQL query, well-structured query, who can help
us shut down the database, pull our records at users, do all sorts of data manipulation, revoking
of user granting of permissions and so on, and so they can spoof data, tamper of existing data and
all these things that they could literally take control of the database itself so we can go to lessen
it now and severity or severity of sequel injection.
So how can we control it?
All right.
So it depends on the attack scale.
So a lot of times if you look at the previous tutorials and we were targeting the most likeable as well
as a we were able to input all this injection and SQL injection works not just for Web application systems.
You could also work for mobile applications.
Ultimately, mobile applications have to connect to some sort of database system or a application server
via application programming interfaces that will then connect to a database system.
So either way, we still have to hurry into a database system, pull our records, cross check records,
and they can also be subjected to sexual attacks, equal injection attacks.
And of course, we also have different types of databases.
So you have Microsoft Access, MySQL, Oracle databases, Microsoft SQL databases.
And what we can do is, of course, depending on a database type, we will also need to man and adjust
our instructions accordingly as we put into sequel injection into these systems.
All right.
And it can also be more common in system classic ASPE confusion in some of the older languages where
they do not try to sanitized input or have some form of protection against those type of attacks.
OK, all right.
So moving on to lesson number nine.
All right.
So we are going to do a string SQL injection.
OK, so over here we have the idea of how the squat queries run, right.
So we have select all from user data where first name is John and last name.
OK, so the user will input a last name.
So this is the input box that would come in from the attacker or from the user.
All right.
So over here we have select all from user.
OK, so John and we have Smith.
So what we are trying to do is to pull out all those records.
So if I click on get account info says no results match.
So we have to find out in what ways are we able to get those details.
So right over here already create it and save those details for us.
So we have a Smith followed by a single KUAT or one equal one.
OK, so over here, Smith with a single code.
So what this does is that it ends all right.
It ends the structured query language here and then over here with or one equal one.
So what we got to do is to have single code for one equal single code one.
All right.
So go ahead and click get account info.
And once you do so, all right, we'll be able to get details of the of all of the quarry.
OK, so over here, this is the one.
So get accounted info.
You have succeeded.
User ID, first name, last name, credit card number, credit card type cookies and log in.
All these details are being pulled out immediately once you run the attack.
OK, so over here on the left side, we have to use your ID.
So again, as mentioned earlier in a previous tutorial behind every Web application system, mobile
application you have, like a Excel sheet is running.
All right.
So Studi Roman columns and we can see all of those details over here.
All right.
So moving on to lesson number ten, OK?
In less than ten.
So we have numeric SQL injection.
Can numeric SQL injection in this case.
All right.
It gives us a warning.
So, of course, the ultimate goal is to retrieve all the data from the user's table.
And we're wanting only one of these views is susceptible to school injection.
You need to find out which to successfully retrieve all the data and count so I can enter, for example,
one and then followed by user ID one and click get account info.
So we just testing out what is the normal expected behavior from the Web application system as we inject
different kind of payloads.
All right.
So this is important as a as a startup, but understanding what the purpose of the input form.
OK, and moving on.
All right.
So we can see over here all this is what we call numeric SQL injection.
OK, so what can we do next?
So I've really created Paillot here.
All right.
So we have, for example, one or OK, single one, single equal single one, followed by seeing a code
again.
All right.
So let's copy this details.
All right.
A payload and the.
The idea is we are trying to check, all right, which of this is actually vulnerable, is it a log
income or is it a user I.D.?
So we got to input forms.
So we need to test which one of them is susceptible.
So go in and get account info could not pass.
And if I do on the second user ID get account info.
All right.
So we got an error message.
So error messages are also very important as part of the response coming in from your payloads.
Please get injected and it could show us whether they are vulnerable or not.
OK, so taking account of the error messages is going to be important as part of validating whether
this sequel injection will work or not.
All right.
So now we can go ahead and enter the following and click get account info.
All right.
So we have identified, of course, user ID is the one that is susceptible to a sequel injection.
So which is why we put our payload into the user ID, whereas login count, we continue to place a proper
input into the login card, which is not susceptible to attack.
All right.
So over here, immediately we are able to get the whole table, our user ID, first name, last name,
credit card, number of credit card type, kookie login count, all this different data points.
OK, so all this the entire table of information has been retrieved.
All right.
So we've done we're going to pass here and we will continue with this tutorial in the subsequent video.
OK, so once again, I hope you've learned something valuable.
And if you like what we've just watched him to, like, share and subscribe to channel so that you can
be kept abreast of the latest cyber security.
Thank you so much once again for watching.