Welcome back.
Time to cover another big topic for an ethical hacker, and that is Web 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 Web site.
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 Web page on point eighty four HTP and on Port for
four, three, four s.
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 its 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 Kleenex machine.
The problem is that an attacker isn't interested in just watching the Web page 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 Web page itself.
We can try uploading malicious files to the server to see whether that will work.
We can test for different user inputs to see if the input is 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 webpage and if that is successful, that code
will be displayed and read by anyone that visits that page after the attack.
This could be some malicious JavaScript code that could send the victim's private information Tavakolian
machine where we can read it.
We could also try injecting different redirection links into the website.
So anyone searching for that page gets redirected to other 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 cover are based on poorly written code.
We know that websites are mainly made in HTML success 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.
Are 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 web page.
Cool.
Right now, the most dangerous one out of these three would be JavaScript code injection or also known
as Crosseyed Scripting Attack or exercice attack.
Why?
Well, the amount 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 our website has a login page where you need to input a username and 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 visitors 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 Ezekial
Queries.
And Ezekial 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 to check it if it's inside its database.
If it is correct, it logs in the user.
If it is not correct, it will print out password incorrect or email incorrect or something like that.
But what if we as an attacker try sending an Escorial query instead of a username, for example?
What then?
Well, there are two outcomes, either the webpage is well coded and it filters out user input so that
the website doesn't allow Ezekial query syntax and it will not even process it to the database or it
is poorly written and it will just forward our 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 Web page.
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 Ezekial queries into an unfiltered user input.
This attack is also known as an actual injection.
You're starting to understand now why this is as important as exploitation of network vulnerabilities
that we did.
Now, another type of attack could be aimed at a server and this would also be an attack through user
input, failed, let's say, for example, we have a website that brings 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 seven five one two one twenty three point
fifty five.
And the next step is website pinging that IP to determine if it's online or offline.
How would they do that?
Well, it would most likely run the pink comment on its system.
So if the website is hosted on a machine, the machine would run pink seven 5.1 one one twenty three
point fifty five.
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 Who am I?
Or as well as we already know, it will all depend whether the user input is well filtered.
If it isn't, it will execute any command that we sent and then we can gain access to that server by
trying to establish a connection with that command just because someone didn't write a 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 is a pretty big thing.
Websites will pay you to find vulnerabilities that we just talked about, and they will pay you a lot
for that.
And as we all 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 visitors input, whether
it's inside a search bar, a user name field or inside of a link.
If that's 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 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 it's 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 sent malicious JavaScript code.
What vulnerability is this?
I will give you five seconds to figure it out.
And it is crosseyed scripting or access 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 we are 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 managed to break.
Or should they say yes, how do we guess it?
Well, we sent a lot of different passwords and hope that eventually we sent the correct one.
That is the entire process behind a brute force attack.
And if the target's account has a weak password and if that password is in the list that we are 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 Ronke 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.