Instructor: Welcome back.
Time to cover another big topic for an ethical hacker
and that is Web App Penetration Testing.
This is another topic that you can further specialize in
if you decide that this is what you want to do,
but what it essentially is
is discovering vulnerabilities and bugs inside of a website.
Why is this so important?
Why are we devoting an entire section only for this
and we didn't throw this inside an exploitation section
for example, as a part of it?
Why aren't we discussing all applications that you can run
on a machine and not just web applications?
Well, it's pretty simple.
Websites are exposed to the internet.
That means anyone can visit it and look at it.
As good as this is, it also brings danger to the table.
Because if anyone can visit it and look at it,
then anyone can also try to attack it. Right?
For example, let's say we have a server hosting a webpage
on PORT 80 for HTP
and on PORT 443 for HTPS.
This website can be any type of website
from chat forum to some university page.
It doesn't really matter.
What matters is that it's accessible to the internet
by anyone who knows it's domain or its IP address.
So just by knowing the name of the website
or its IP address, anyone can look at that website,
even us from our Kali Linux machine.
The problem is that an attacker isn't interested
in just watching the webpage
and using it as its plan to be used.
An attacker will try to execute different types
of the attacks from code injection to brute force attacks.
If there is a login page.
the attacker can even try extracting data from the database
and changing the code of the webpage itself.
We can try uploading malicious files to the server
to see whether that will work too.
We can test for different user inputs
to see if the input is well filtered
or is the website code written poorly
and doesn't filter any input whatsoever?
You know what the best part is about all of this?
A poorly written code that makes website vulnerable
to some type of the attack
doesn't only present danger to the server
hosting that website,
but it also presents danger
to everyone that visits that website as well.
For example, we can try to inject code
into a certain web page,
and if that is successful
that code will be displayed and ran
by anyone that visits that page after the attack.
This could be some malicious JavaScript code
that could send the victim's private information
to Kali Linux machine where we can read it.
We could also try injecting different redirection links
into that website, so anyone searching for that page
gets redirected to our malicious website
where we can steal their information.
Imagine we do something like this
on a website as big as PayPal.
That would be a big problem, right?
That's why web penetration testing is so important
and most of the attacks that we will cover
are based on poorly written code.
We know that websites are mainly made in HTML, CSS
and JavaScript code.
All of them can be used to attack websites
with code injection,
and what code injection is
is simply writing code somewhere
where you shouldn't be writing it.
For example, let us say a website has a search bar
where you can search different book titles.
A regular user would type book titles in that search bar
in order to find a book that they want to read,
but an attacker would try writing code there.
It might or might not work.
If the user input,
which in this case would be a book name,
is poorly filtered
and it allows anything to be written there
then the code injection will most likely work
and we will be able to inject code into that webpage.
Cool. Right?
Now, the most dangerous one out of this tree
would be JavaScript code injection,
or also known as Cross-Site Scripting attack
or XSS attack. Why?
Well, HTML is static, and the only thing we could do
with an HTML code injection
is to change the look of a webpage.
While with JavaScript, we can execute various functions
which give us much more power.
Another thing that we can try is to communicate
with the database.
For example, let's say a website has a login page
where you need to input a username and a password.
Usually big servers and websites
will store those usernames
and passwords inside of a database,
and every time a visitor of the website tries to log in,
the server will then communicate with the database.
It will compare the visitor's input
of username and password to see if they match
with something from their database, and if they do,
then the website will log in the user to their profile
and the user will have access to all of their data.
This type of communication between the website
and the database can be done
with something called SQL Queries.
And SQL is a language
that allows us to interact with databases.
It is heavily deployed in websites.
Now, this right here
is an example of a normal usage of a website,
so the user sends username and password,
website checks it, if it's inside its database.
If it is correct, it logs in the user.
If it is not correct,
it'll print out password incorrect
or email incorrect or something like that.
But what if we, as an attacker,
try sending an SQL query instead of a username,
for example, what then?
Well, there are two outcomes.
Either the web page is well coded
and it filters out user input
so that the website doesn't allow SQL query syntax,
and it'll not even process it to the database,
or it is poorly written
and it will just forward our as SQL query to their database.
And this can be critical because we can send
a query where we request the entire database back
and the database will just send us
all of its contents where we will have
everyone's usernames and everyone's passwords
who have an account on that website.
That would be really, really bad,
and that is the reason
this is one of the most dangerous attacks
that you can do on a webpage.
It is also one of the most common ones as well.
Ever read the heading inside some newspaper that said
something like, 10 million credit card numbers stolen
or some big website got millions of passwords leaked?
Well, now you know how they do it.
They do it by injecting SQL queries
into a non-filtered user input.
This attack is also known as an SQL injection.
You're starting to understand now why this is
as important as exploitation
of network vulnerabilities that we did.
Now, another type of the attack could be aimed at a server
and this would also be an attack through a user input field.
Let's say for example,
we have a website that pings other websites.
You input an IP address of a different website
and our website will tell you
whether that other website is up or offline.
So we could type for example, some random IP,
let's say 7510123.55,
and the next step is website pinging that IP
to determine if it's online or offline.
How would it do that?
Well, it would most likely run the ping command
on its system so if the website is hosted on a machine
the machine would run ping 75.101.23.55,
or if it is hosted on a server,
the server could execute that command.
I believe by now you can already see
where the problem can occur.
What happens if instead of an IP address,
we send a different command, such as WHOAMI or LS?
Well, as we already know,
it will all depend whether the user input is well filtered.
If it isn't, it will ll execute any command that we send
and then we can gain access to that server
by trying to establish a connection
with Netcat command
just because someone didn't write website code well.
All of these things that we discussed
are also known as bugs
or you might have heard about the term bug bounty.
It's a pretty big thing.
Websites will pay you to find vulnerabilities
that we just talked about
and they will pay you a lot for them,
and as we already know by now,
all of these vulnerabilities happen
due to poorly written code.
Or in other words these vulnerabilities can occur
anywhere where the website will process a visitor's input.
Whether it's inside a search bar,
a username field, or inside of a link.
If that what you send to the website is getting processed
and it doesn't get filtered,
then we could have a bug.
I will give you another example right here
just so you can test
and try to figure out which vulnerability this is
out of the three that we mentioned in this video.
Let's say we have a website
where you can watch videos or movies.
So its got a search bar where you can input a movie name
and then it will display the movies that you search for.
And now let's say that instead of a movie name,
you send malicious JavaScript code.
What vulnerability is this?
I will give you five seconds to figure it out.
And it is Cross-Site scripting or XXS attack.
Don't worry if you didn't remember it.
Each of these attacks we will cover in details
and we will see a practical example of each one of them.
And also besides these attacks
we will cover what I believe most of you also interested in
and that is brute force attacks.
And these brute force attacks are
pretty much simple to explain.
It is not a vulnerability
it is just a poor password or a weak password
that someone uses that we manage to break
or should I say, guess.
How do we guess it?
Well, we send a lot of different passwords
and hope that eventually we send the correct one.
That is the entire process behind a brute force attack.
And if the targets account has a weak password
and if that password is in the list
that we're using to brute force,
then it's pretty much game over.
We will be able to get it.
Now, this can also come with different difficulties such as,
if the website blocks inputting passwords
after five wrong attempts,
but this can also be bypassed.
Nonetheless, these are some of the most known
website attacks and in this section
we will see how to perform each one of them.
See you in the next video.