Hey guys, hackers, Floyd here. And in this video, we're going to get started with the web
application penetration testing series. Alright, so a lot of you guys have been asking for this,
mostly because you want to learn the art of bug bounty. And here is the series. So have worked
really, really hard on, you know, making it as comprehensive as possible, we're going to get
started with setting up burp suite. So for those of you who don't know, what works, who it is,
burp suite is essentially an integrated platform for performing security testing
of web applications. Alright, so the first thing you need to understand is that it will allow us to
intercept the data being sent between your browser and the web application. So it's, it's a great way
of understanding how data is being transferred, and how data can be manipulated, be manipulated,
between the client, and obviously, the web application. Okay, so the tool we're going to be
using, as I said, is burp suite. And I'm currently running power to us. So don't worry, if you're
running Windows or Kali Linux, it doesn't really matter, all we need to do is just download and
install burp suite, it's pretty simple to get set up, you don't have to register, you just download
the free community version. Now, obviously down the line, you might choose to buy the professional
version, which I do recommend and I have used, but I don't use it as often I'm not, you know,
specifically a web penetration tester, I'm more of a more of an of a web server penetration tester.
So I really work with a different vectors. So by default, you can choose to bite that one to
become experienced. And you know, you've chosen whether this is the path that you want to pursue,
it's a fantastic path. I know a lot of people who you know, make good money with bug bounty. So you
know, it's something that you can look into as well. Alright, so let's get started with
setting up the proxy. Alright, so this is the intercepting proxy that allows us to, obviously,
to intercept the data being sent to and from the client and the, the web, the web application.
So to do that, we need we can just do it through Firefox. So the browser I'll be using is Firefox,
you can use whatever you want. And by default, you want to go into your preferences that can be found
here preferences, there we are. And you want to go all the way into the bottom here. That way it
has the network proxy, and make sure you go into settings, and you want to go into manual proxy
configuration. Alright, so this is where we're going to configure it to be the localhost with
the port set at 8080. All right, and then you want to make sure that this, you use the server proxy
for all protocols. So that is the proxy we're going to be using and just hit OK. Alright, and
once that's done, you should be good there. Now what you want to do is just open up burp suite, so
you can search for it, or I have it already on my on my little Taskbar here. And I don't think I've
updated it for a while. So I probably need to do that later. But for now, I'll just close that the
update prompt and it's going to prompt you Welcome to burp suite. And it's going to say not depending
on the version that you've chosen to select whether you've chosen the community version,
which is what I have here, or the free version, as it's called, and you then have the pro version. So
by default, the community version only allows you to use a temporary project, if you have the
professional version that allows you to save your project, which is, you know, great functionality
as well. So just hit next and you just want to use the verb defaults. And just hit start.
And just give that a few seconds to start it up. Alright, and I'll explain the interface generally,
but we'll be looking more into how burp works. In the next video, I just want to get you set up
with birth in this video, and you understand what exactly is going on. Alright, so welcome to birth.
Now by default. Again, it may seem a little bit intimidating mostly because if you're a beginner,
you have not heard of any of these of these words here and you don't really know what they're doing.
Alright, so by default, you have your target proxy spider scan into the repeater, sequencer, decoder,
compare extender, your project options, your user options, and alerts, we'll be going through all
of this as we as we, you know, perform real world testing on our on our vulnerable on our
vulnerable target, I'll be showing you how to set up a dam vulnerable web application soon,
and many others but for now just focus on burp suite. Alright, so by default, you want to just
go into proxy. Alright, and for some reason, I already have some data here. So you know what, I'm
just going to leave that as it is, I just want to turn our intercept off. So we're not intercepting
any traffic as of yet. And you want to go into your options. And you want to make sure that your
proxy listeners, as you can see, burp proxy uses listeners to receive incoming HTTP requests from
your browser. So you want to make sure that your proxy is set as the as the one we set in Firefox,
which is the localhost 120 7.0 point 0.1 and the port is 8080 and make sure that that is running.
Alright, you can also create your own and add it here and you're going to To remove it, so you get
the idea. Now by default, if I just go back to my intercept, if I just go back to my browser,
and this is where the real magic happens, if I just, you know, if I just open this,
and I type in a simple test site example.com, and I just hit enter, alright, it's going to load it
up here. But if we're going to burp suite, and I go into HTTP history, you can see that by default,
there are some Firefox portals. You know, some get methods here. But we'll be looking at all of
these methods or requests. By default, you can see that the example.com, the example.com, one would,
you know, that we ended, you can see there is a get request. And furthermore, if you go down to
the bottom here, you can see there is some more information regarding now what a request are sent
to the web application. Or so by default, you can see that the host was example.com. And it gives
you more information, like the Accept language, the encoding, the connection. And if you look at
the headers, you can see that the header shows, you know very clearly, you have your get host,
use agent accept language, the Accept encoding, connection, etc, etc. So you might be a little bit
confused if this is your first time hearing about, you know, headers, and the request and response
pairs. But don't worry about that we'll get to all of this for now, if I just go back into intercept,
and let me just open up my browser here. And we open something like the my web, my website,
would you say it just like.com. So before we do that, I just want to hit intercept on. Alright,
so now it's going to intercept actively. And we just go into Hs pro.com. And I hit go. Alright,
now by default is going to tell me that essentially, the mic connection is not secure,
don't worry about this, just go into your and just add this as an exception. There we are
made confirm exception. And now it's still not going to load the website. And the reason being
is we have not forwarded the request. And they are being intercepted by burp suite. Alright, so if I
go into back into burp suite, you can see that it has started the intercept process. And by default,
you can see that we need to forward we need to forward the request here. So if I just forward it,
let me just for that again, there we are, let me just for them for hackers out there. Yeah,
that's the correct one. So all for this again. And there. We also know hackers blade should
be up and running. And as you can see, I should have loaded the site. Give that a few seconds.
There we are. Alright, so as you can see, that is how you intercept the data that is being sent
from the client to the web application. And furthermore, that's how you, you can analyze
the data being sent, and furthermore manipulated to obviously find vulnerabilities within the web
application. Alright, so irregardless of all of this, I know, this was very, very basic,
and it's not really covered anything in terms of web application penetration testing. But
don't worry about that, you know, we start off really, really simple. And we build on that.
We're going to get started with spidering, more specifically spidering, with burp suite. And,
you know, the purpose of this video or this tutorial, is to help you understand the
spidering process and how to go about doing it with a burp suite. Alright, so there's
going to be a little bit of theory here, but I'll be explaining a lot of things. So again,
this video is really focused on understanding spidering. Now, before we get started with that, I
just wanted to let you know that the target or our web application that we're going to be targeting,
we're going to be attacking is the damn vulnerable web application. Now, if you don't know what the
damn vulnerable web application is, that's fine, you can just Google it. And I'll probably make a
video on how to get it installed on Kali Linux. But what I would recommend if you're, you know,
beginner, or even if you're a professional in hacking, probably one of the best things that you
need to have, you know, in your kit is Metasploit able to write and for the simple reason that it
contains, first and foremost a vulnerable operating system. And secondly, it contains
all the vulnerable web applications that we will be using at one stage during this series. Okay,
so we're going to be starting off with the damn vulnerable web application. As I said,
it comes pre installed with meta splittable, too. So all you need to do is get the local IP address
on your mat, exploitable to virtual machine, which in my case is 190 2.1 68 point 1.1 a dupe.
So what I'm going to do is I'm going to open up my browser, and I'm just going to open up that
webs that IP address point 1.1 or two, and just give it a few seconds to load up. As you can see,
there we are, that's made exploitable too. And it's going to prompt us to select what vulnerable
web app we want to use. In this case, we're going to select the DV w A, which is the dam vulnerable
web application. So just click on that and it's going to ask you for your admin and password in
this case for your username and password Sorry about that, in this case Your username is admin
and the password is password. Alright, so just hit login, and it's going to log you into the
damn vulnerable web application. Now we'll be looking at this at a more in a later video. And
the reason is we have to go through all of these options. But for now, if you go to the login,
just remember where it was, if I can just go to the security, so to the dam vulnerable web
application security, at the moment, it was high, because I was actually performing some tests on
it, but just change it to medium or low. But for now, you wouldn't be using it. I was just letting
you know what web application we're going to be using. Alright, that being said, let's move on
to burp suite. All right, and we can I can start explaining the spidering process. Right. So let
me just open up burp suite. So I've updated it to the latest version. I think I'm running Catalina
next now in the previous video, I was running parrot. So I think there should be an update,
but I could be wrong. So let's just give that a few seconds to start up yet there is an update. So
I'll do that later. And we'll just click on create our temporary project and use the bap default and
start that. Okay, so once that starting, let me explain what spidering is right now the
purpose of spidering is to identify our scope, alright, or what, what we want to scan. Now this
is not exactly scanning, and we'll be looking at scanning. But essentially spidering is the process
of mapping out our web application, and is very, very useful for finding links and and web forms,
which is also very important because it will allow us to then furthermore, attack the web forms
manipulate headers, etc, etc. Right now, when you talk about automatic spidering with burp suite,
it essentially when when burp is spidering, it follows links and it will, it will start
following links and it will start identifying for files, folders and forms from the web application.
And it will, the great thing about this is it will record all the requests and responses while it's
performing the the old spidering process. Okay, so once you have a burp suite opened up here, you
can let me just expand it. So we have a greater picture of what's going on exactly. Sorry, if my
virtual machine is a little bit slow, I need to configure it correctly. Anyway, what you want to
do is we have looked at the proxy check section, let's look at the spider section. And in here,
this is a very, very simple menu and to understand it, you can see that we have two tabs available,
we have the control tab and we have the options tab. Alright, the control tab. Essentially,
if we just click if I just look, if we look at it, as you can see, these settings are used to monitor
and control the web spider. So it allows you to stop to start and stop the burp spidering. And
you can also clear the cues. Alright, when you look at the options, which is right here, sorry
about that, when you look at the options, there are a lot of options, we'll be looking at them,
I will be looking at them in a second. Sorry about that, I actually got an email, apologies
that. Let's get started. Now with the control section. So the control section, it will all
we are able to control the spider status where we can stop it and started and you know, furthermore,
we can clear the cues that already exists there. Alright, we then have the spider scope where we
can, we can define our own scope. And depending on what we want to spider, we look at that in a
few seconds. And finally, we look at the well if we look in the Options section here, we have the
crawler settings which allow us to specify the way the spider is going to crawl for the web content
on the web application, we'll be looking at the maximum link depth and what that means passive
spidering that allows us to essentially spider to continue spidering when we are looking through or
we're going through the web application, we're performing requests and responses when we're
performing requests. As for the form submission, this is probably something that we'll be looking
at in the next video and we'll be doing this. Practically we will be actually performing the
we'll be performing the spidering process. But for now, let me see what else Yes, the request
headers. The request headers are used to you can manipulate essentially the headers. If you've
learned about HTTP headers, by the way, I really want to cover HTTP because it's very important
that you understand how the ad is work. But we'll be looking at this all in advance. But now let's
start off with the spider status. Well, not really with the spider status. But looking at the control
tab. If you look at the spider scope, you can see that you can it will use the default suite scope,
which is defined in the target tab. If you just click on use a custom scope, you can see that
Okay, first, you over, if you just click on this little cog here, you can restore the default, you
can load your own and you can save the options. So that's just to do with that. Now when you talk
about using the advanced scope here is where you can essentially this is where you specify what you
want to map so you can specify a host, the port, etc, etc. Okay, again, we'll be looking at all
of this as We move along. But for now, we're just going to use the default suite scope, we can just,
if once you click on that, it's going to start the spidering process, but we don't need it right now.
So I'm just going to come just going to pause it. And if we move on to the options now the
Options tab has a lot of stuff that we need to look into. First and foremost, we have the CRO,
the crawler settings. Alright. So when you're talking about the basic options, for example,
we can specify what the spider will crawl for. So it you can choose to select for robots,
the robots dot txt file, which is very important because it shows you, you know, exclusions,
you then can detect, you can ignore the links to non text content, you can request the root of all
directories very important stuff. But again, you can customize this to your liking. Now,
one of the things I would recommend that you'd not touch with, if you do not know what you're
doing yet is the maximum link. That's right, the maximum link depth is essentially the number of
links you want the spider to, to essentially, to crawl or to map. Now by default five is in my,
in my, in my situation, or in my case, what I like doing is alternating between three to five,
anything higher than that will usually overload the web application, and it will cause it to lag
or to respond very, very slowly. And, you know, again, that might not mean a lot right now,
but trust me, when you'll actually be performing the penetration test on the web application,
you really need a good response. Otherwise, you have your time to live, etc, etc. Okay,
so let's look at what passive spidering is, alright, so as passive spidering. And said,
is essentially just, it allows you to continue scanning, you know, or going through, or
actually performing your requests how as as it, it essentially allows you to continue the spidering
process as you're performing any other tasks. So as you can see, passes by during monitors,
monitors traffic through the burp proxy to update the sitemap without making any new requests,
right. So passively spiders you browse, you can also select the link depth associated with proxy
requests now this, I would recommend keeping it at zero to two. And that's because again,
you do not want a very, very deep alert link depth in the sense that you're also going to
be performing your own requests, and you'll be doing many other things you could be looking
at the decoder or you could be looking at, you could be focusing on the target,
and you don't want it again to to slow down the web application. Alright,
so form submission. Again, this is something that I said we'll be talking about in the next video,
because it is quite advanced. And we'll get started with the damn vulnerable web application
there. Moving on to the spider engine, we'll be looking at application login as well. But for now,
just we'll just keep over that when we talk about the spider engine. Alright, these settings
control the engineers for making HTTP requests one spidering. Right. So this allows you to change the
number of threads you want to use. And as I said, using more than we can see right now it's at 10,
what I would recommend is still keeping it within the range of two to five are all you might,
you might cause the web application to slow down. And these are more advanced settings that
you can use dependent on timing. All right, and we've talked about the request headers,
they allow you to modify the way the spider will we look towards the web applications, for example,
you could you could edit the the device that is being used. And you could change it, for example,
into a mobile device and you get the idea you you essentially allows you to to change the request
headers. And from that, obviously, you'll get a response back, dependent on what you changed.
Alright, so that was the spidering, or actually the theory revolving on spidering. Now we'll
be looking at how spidering really works in the next video. I know some of you may not like this
that I actually went through through theory, and I haven't talked about doing anything. But remember,
it's very, very important to understand what exactly is happening behind spidering. And
in the next video, we'll actually get started with the spidering process.
Get started with brute forcing with the rates or our vulnerable web application of choice is
going to be the damn vulnerable web application, as we discussed in the previous video, alright,
and I'm going to be using meta exploitable to as our as my server. By default,
you can install medispa, you can install the damn vulnerable web application on your Kali Linux,
and you can host it on your local on your local server. And you can you can then perform your
attacks. But I like running it from another virtual machine. And as you can see, I'm running
it on the Metasploit able to virtual machine. And by default, it's connected to my local network
and it's bridged. So you can see that my local IP address is 190 2.168 point 1.1 or two. Alright, so
I already have the damn vulnerable web application open as you can see it is running on the that IP
address of the meta splittable to virtual machine on the the damn vulnerable web application. So for
those of you asking why I'm using Metasploit able to instead of meta splittable. Three, it's because
Metasploit able to has a much larger choice in terms of vulnerable web applications. And it's
really good for practicing. Alright, so make sure you're logged into your damn vulnerable
web application, you need the default username is admin and the password is password. Alright,
it's really very simple. Alright, by default, In this video, we're going to set our security level
too low. If you don't know how to do that, you can go into your deverbal web application security.
And you can set that too low, and you can just hit submit. The reason we're setting it too low is
because most logins Are you know, if you look at the real world, if you're talking about big sites,
this attack may very well work on sites that are older, or sites that have not been updated,
or sites that don't have good security, you'll be shocked to find some really big companies
that actually don't have any login protection, or brute force protection for that matter. Now,
that being said, what I was talking about is if we go to brute force, you can see that we have
a login prompt here. Now I forgotten the username and password, and we're going to be brute forcing
it live. Alright, but before we do that, we need to actually start our birth. Alright, so
start up that suite. And you can see I'm using the Community Edition. And it is the latest version,
right? So make sure that yours is the latest version, obviously, for obvious reasons. And
we're just going to start a temporary project because I don't use the pro version. And we're
going to hit use the birth defaults when you start work. Alright, give that a few seconds to start
the to start back. And now you want to make sure you you're using the proxy. So we're going to go
into preferences, and advanced and whoops, burp is oh opened up, let me just go into my proxies,
network settings. And we make sure that it's using the manual proxy configuration,
which is the localhost 120 7.0 point 0.1. And the port is 8080. We're gonna hit OK, excellent.
Now we need to move into burp back again. And we want to make sure that we go into proxy,
and the intercept is set to off. All right, the reason we're setting the intercept off,
is because I just want to show you something first. Now by default intercept essentially just
means that you're not intercepting the request, the requests and the responses being sent from
the web application to your browser. Okay, so we have already set the proxy for the browser,
but we're not intercepting. So if we just test a random username like test, and we say a password
like 12345, you can see if I hit login, it's going to tell me that that is incorrect. Now,
if I set the intercept to on to see the request, let me just turn it on. And we can now reload this
we can say test and the password 12345. We can see that now it's for some reason, let me just
forward that after actually just turn that off. And we now see log in. And for some reason that
is not allowing us because you have to reload. Alright, so now if I hit intercept on, and whoops,
let me just open up my browser and hit the parcel 1345. Log In. For some reason it's going to,
it's going to slowly reloading here. I probably there we are. Alright, so I've reloaded the page.
And as you can see, now the intercept is on and we go back to burp, you can see that we got the
get request being sent by the web application. Now let's inspect it for a while now we'll be
looking at what all of this really means but by By default, the most important thing right now is the
get request. Alright, so you can see that the get request has two values here. It has the username
and the and the password. Now the values again are not important we're going to be brute forcing the
values but it's very important to get the fields that we're using here. Now what am I talking about
if you look at the cookie you can see the security is low. And if you were to edit the value and for
the package, you can set it too high that is basic stuff that's good stuff right? But now we want to
brute force this login. Alright, and how do we do that you can see the first thing we need to do is
we're going to be using the intruder alright so if you're a bit confused about what the in today's
Don't be worried intruder is essentially allow allows us to edit the parameters, it allows us to
edit the requests and then obviously edit them and manipulate them so we can get the desired results.
Now the great thing about there in the intruder is it allows us to perform attacks like the brute
force, etc, etc. Alright, but now what we need to do is we need to send this request into the
intruder so that we can send our own response. Alright, so we're going to right click and send
to intruder. So we just send it to intruder. And once it's sent to the intruder, you can just hit
forward. Alright, we don't need window, we don't need that GET request anymore. So now you want to
go into the intruder and you want going to your positions. And as you can see in your positions
you have got you have got the get request that we were we just intercepted. And now you can
see something really interesting. It's highlighted for you all the different payloads. Okay, all the
different fields that we can brute force for. By default we have the username value, the password
value, the login value, we have the F the SF ID value, we have the the cookie value, no No, no,
we don't need all of these The only values that we need The username and the password value. So the
most important thing you need to do right now is you need to clear just hit clear. Alright, oops,
sorry, not that clear. I beg, I beg your apology there. I sorry, I didn't mean that what I'm trying
to say is I'm sorry, just clear, just hit clear. And as you can see, now, no values are being
selected to be brute force against. So now we need to select them manually. But before that, we're
going to be using the the cluster bomb attack type. Alright, the reason we're using the cluster
bomb attack type is because we are going to be using two values, we are brute forcing against
two values. Remember that, okay, and these need to be set in, in combination. So that means it's much
better to use a cluster bomb because essentially, you're clustering to values that need to be that
need to be tested against the login, the login application, or the login form together, alright,
so in a combination, so we need to select cluster bomb. And now we need to select the values because
those are the those are that is what we want to brute force again. So just highlight the value,
it doesn't matter the password or the username is just highlight it, and you want to hit Add.
Alright, so just hit Add. And as you can see, we have selected that, you know, going to the
password, and you want to highlight that as well. And you just want to add that, as you can see
now once you have added that those are the two values we're going to be brute forcing against,
make sure that none of the others are selected none of the other values. Once that is done,
you're you're almost there now. Now you want to go into your payloads. Right now in your payloads,
you want to make sure that your payload set is set to two, which is your username and your password.
So let's start off with your payload set as payload one, all right as your payload type,
make sure that that is a simple list. Because you can see we were only targeting usernames
and passwords. So we don't need, you know, a runtime file, or we're not changing anything,
you know, dependent on Unicode etc, you get the idea. Okay, so simple list. And now you're going
to your payload options, which is where you select your user list or your password list or your word
list. Now, we're not using a word list. But if you want to, you can if you're performing this
on a real site, which I don't recommend unless you have written permission. Now since we're
using this in our penetration testing lab, we are going to just add the default usernames and said
the security of the site is low. And it's not really a complex a brute force to crack. Okay,
so what we want to do is, we want to make sure we have set payload set to one, which is going
to be for our usernames. So now we can go into load where you can load your default usernames
and your passwords or your word lists, but by default, we're going to add our own Alright,
so we're gonna say, whoops, we, for some, we're just gonna say, we're going to type in a now like
the commonly used usernames, alright, so something like admin, administrator whoops, for some reason,
actually, let me just remove these blank values there. admin now administrator, administrator, let
me just type that back in. administrator, like, so administrator, for those of you telling me that my
typing is bad. That's because my microphone is right in front of me, and I can't really
see what I'm typing administrator. Let's see what else what are the default ones like we have root,
we have password. Actually, we're not setting the passwords right now. So we can just type in
the default ones like this. All right, so we can say test, you know, the default ones, user one,
whatever you think could be the most commonly used ones, okay? Or if you know what the username is,
that is even better. So we're gonna add all the usernames. Alright, so we've added the usernames
that we want to use. Now by default, again, I'm saying you can use a word list if you want to just
go into load and select the word list. Now we want to select our passwords, right? So we can go into
the payload set to. And as you can see, now we can add our own values. Now we can use the default
word lists that come with Kali Linux. So if I go into my root, and I'm going to use them, share and
reselect word lists, let me just find where word lists are. If I can find them, there we are word
lists. And they are the ones that work great for me in the Metasploit folder. And you can look for
the default passwords. As you can see, you have your database default passwords, you have your
default, user password for services, that's also great. It has a great list of of default usernames
and passwords that you can use. But for me, I'm not going to use this because we are sticking
to the basics. And now you want to add your own password. So we can select again, some randomly,
you know, commonly used passwords. So pass, you can say password. Let's see what else admin, you
know, admin again, whoops, let me just remove that one admin. Route, you can use route. Let's see,
let me think 12345. That was the one that I've seen many network administrators using 12345.
And you get the idea. All right, so we've set our two payloads. payload one is set for usernames.
payload two is set for passwords. Excellent. All right now, we have selected our payload types we
have selected we have added our payload options. We don't need to look at payload processing that
is advanced once That's done, what you want to do is going to intruder and start the attack.
Alright, and now it's going to tell you that the Community Edition of burp contains a demo version,
but it's essentially telling you that the process is going to be slow. Alright, so we're gonna hit
OK. And it's going to start at the attack. As you can see, it's going through all the combinations.
And as you can see, the combinations that we have here are 25, and is going to go through
all of them. Now, one great thing that you need to do here or one important thing that you need to do
is you need to understand the the the status codes that the server or the web application is sending
back. Now, that's a good way of, of understanding what password is correct? And what what username
is correct and what password is not correct. Okay. So if we look now, at the, at the results,
as you can see that it's finished, it's going through the brute force attack, we check the
status, the status is still the same, we have a status to 200. If we look at the length, right,
the length is going to be still the same. But you have to look for things that are not that are not
matching. So for example, you can see that the length here that was returned was 4948. And it's
not, it's not following the format of the others. So that means that this could be the username
and password, don't worry about the status, the status will still remain the same, regardless of
that. But when we'll be looking at Advanced Server penetration testing, that's something important.
So you can see that the get that we've got here is very important. Now if we look at the if we look
at the response that will be sent. Right there, you can see the response. And if we render it,
you can see that if it was successful, it will tell us that we've logged in successfully. So let
me just browse down all the way as you can see, welcome to the password protected area admin.
And there you go, that is the username and the password is admin and password. Now again, this
was really simple. Again, you can you can increase the security if you're practicing on your own. But
you can see that this really works. And this is how to utilize burp for advanced stuff like brute
forcing. Now again, most of the advanced websites nowadays have great content management systems
that have the security plugins that essentially prevent you from brute forcing or lock you out.
But most of the oldest sites, you'll be, you'll be actually quite shocked to find out that they
are brute forces, they are log informed sorry, are not protected. Now we've already logged in,
and you can see that the default username is admin, and the password is password. Okay, so you
can look at the role. The raw HTTP here, you can look at the request and the response. Or you can
look at them and you can inspect them, if that's what you do. And you can look at the headers,
what's being sent, all that good stuff. But that was going to be it for this video. And now if we
just go back into burp, let me just go into my proxy. And I'm going to disable intercept. And
we can try and log in here. So we know that the admin username is admin and the password
is password. So let me log in. And welcome to the password protected admin area fantastic.
In this video, we're going to be looking at selecting our verbs with our target in web suite,
adding it to our scope, and then finally spidering it as my vulnerable operating system, I'm going to
be using the Matilda de which comes pre installed on Metasploit able to so you should download Well,
I would recommend that you download Metasploit able to, it's a fantastic option for any of you
who are just getting into penetration testing offers multiple vulnerable web applications
and vulnerable systems that you can practice with. So again, it's something that I really,
really recommend. That being said, as you can see, I have made exploitable to virtual machine
running. And I have already looked at my local IP address, you can do that by typing in if config
that will display to you your your current network interface and your local IP address. Because we
are doing this in our virtual penetration testing lab. Alright, so let's go back to Kali Linux now.
And I'm going to open up my browser, make sure you get your IP address. And as I said, again,
we're going to be using motility. So if you don't know what Mattila day is Mattila day is simply a
vulnerable web application. And the reason I'm switching I'm switching from the damn vulnerable
web application is because I want to show you a few, I really want to make it a bit diverse
in terms of the web applications that we use. Alright, so let's get started now. Now I already
have the IP address of my virtual machine opened up here in my browser, as you can see, 190 2.1
68 point 1.14. So if I reload this, you can see that it indeed is the meta splittable to server
and I can just go ahead and click on Mattila day. Alright, now what I should do now is go
into my preferences, you can do that by opening a new tab. So let me just open a new tab here going
into preferences, and then selecting advanced and network and finally settings. And then you want to
make sure you select a manual proxy configuration. And then make sure it's using the localhost proxy,
which is wondering 7.0 point 0.1 Port 8080 and hit OK. Once that's done, we know that burp suite
can intercept. Not that we want to do that in this video, we just want to, we want to have a look at,
we want to map the web, the web application. Alright, so we're not going to change anything
in Mattila day. But I'm going to be showing you some pretty interesting things in this video.
So now we should start up burp suite community. Now I'm going to be explaining something at the
end of the video that is really important. And it is in regards to the community version, and the
professional version of burp suite and what what the differences are and why you will need at some
point to get the professional version. Okay, so I'm going to select a temporary project, I'm using
the community version as of right now, hit Next, use the bird default, and I'm going to start up.
Alright, so it's going to start burp suite. And let me just minimize the browser here. So give
that a few seconds to start up. And once it starts up, what you want to do immediately is turn off
the proxy, we want to stop in the intercepting because we are not intercepting any requests,
or we are not inserting any responses. So go back into your target. And now we can get started with
with actually reloading the page right here. So let's reload that. And we should be able to see
what's going on. And we should have the sitemap. Alright, so let me just open up the burp suite
here. Fantastic. Alright, so now you can see something very interesting has happened here.
In our target. And sitemap, we have the files that were discovered here. Well, essentially, we have
the web server that then has the modality folder, which is our target. Now before I get into any of
that, the site map will show you the current site map. Obviously a site map is essentially
sorry about that a site site map is essentially the structure or the format of the webpage,
and how the web page was constructed and how it will function in regards to every other piece of
content. Okay, so the first thing that we need to do, or we'll be looking at is actually selecting
our target, which in this case, again, is Mattila day. And you can do that by right clicking and
hitting add to scope. All right, so you might be asking what exactly the scope means? Well,
a scope essentially allows us to define our automated spidering. And what this means is
we are focusing our only on our target, we're not going to focus on the reference links,
like you can see here, for example, we have to it as a reference link, backtrack, dynamic drive,
Eclipse, etc, etc, you get the idea. So scoping is essentially selecting our target, isolating it,
so that we only see what we need to see. And the obviously the results that we want to see.
So I'm going to right click on Mattila day, and I'm going to hit Add to scope. Alright,
so now it's going to say you've added an item to to the target scope, do you want that proxy to to
stop sending out scope items out of scope items to the history of the other bedtools? Yes, again,
we want to make sure that we are we clear out all the junk that we don't need. Now you might have
noticed? Well, that's essentially happened, but nothing is really changed. And as you can see,
it's gonna tell you here logging of out of scope, proxy traffic is disabled, don't worry about that,
just leave it as it is, if you want to re enable it, you can go ahead but right now you
don't need to do that. Okay, so we've looked at how to add our target to the scope. Now,
let's look at spidering is essentially the the first and the most important step of web
application penetration testing. Alright, it is it deals with or it is in it is in
relation with footprinting. And this is why I bring the comparison from penetration testing
to obviously web application penetration testing it is to deal it essentially deals with crawling
through the website. And then it records all the files, the links and the methods and the methods
that it can get. And that helps us build an idea of how the web application is structured, how it
works. And then finally, we can learn how we can break through it. What we need to do is we need to
spider our target. Well, we have added it to the scope, which is great. And now we need to spider
it. So what we're going to do is we're going to we're going to use spider and this will help us
identify all the links and the parameters that we need. Again, as I said, it's like footprinting. So
what you want to do is right click on your target, which in this case is Mattila day,
and you want to spider this branch. Alright, so I'm going to spider this branch. And no,
something interesting is going to start happening. As you can see, it's going to start getting all
the links all the resources that it can, and it's going to prompt you with here a submit form. Okay,
now, what you can do is just ignore the form, there'll be quite a few essentially, these are
default login forms where it's asking you to enter credentials that you might want to enter,
let's say you, you're performing whitebox, then Richard testing and you have the details. You
can again log in like this and perform internal penetration tests. But we're going to assume
that you're you do not know your penetration, you're essentially performing a penetration
test on the security. So I'm going to ignore all of these forms. Okay. And as you can see,
there's another one right there and the spidering is probably continuing. Now if you want to view
the status of these By doing, you can go into spider. And as you can see you have the status
of the spider. And once it's done, you will see that the requests made will stop changing. And
the bytes transferred, will also stop changing so we can stop the spider. Now you noticed something
that we were faced with those are form login prompts. Now, you can choose to enter them as
a prompt or as you're prompted, but the better way of doing this is to actually you actually do
this automatically. And you can do this by going into spider. And you want to go into options,
and you want to go in to your application login. Alright. Now, if you look at the form submission,
it is essentially what it's doing is is going to use the default form submissions that you would
find in a database. So for example, we have male, first name, last name, surname, name, address,
you get the idea. So those are default values that one would, one would be expected to find. Now
we're looking at the application login. As you can see, its option is set to prompt for guidance, we
want to change this to automatically submit these credentials. Now in here you can enter default
credentials. Or if you have an idea of what the credentials you might expect to find. Now, this is
where creativity and sheer information gathering comes into play. So if you need a new the default,
you know, usernames and passwords, you can enter them here. Now what I'm going to do is I'm going
to enter a string that is, well, I've used it before in performing SQL injection, and we'll talk
about SQL injection because it is very advanced. If you know SQL injection, or you have you have
an idea or experience with the databases, you might understand what this string means. Alright,
so for my username, I'm going to change that to admin, quotation mark and say, or one equal one,
and two dashes. All right space and a dash. Now you don't need to worry what this means for now,
please do not stress about this, I will explain it when the time is right. All right. So leave
the password as it is. And don't worry about that. Now, we had, we don't need to change anything in
terms of these tabs, we talked about these tabs in the theory section. And now we can go back into
our control and target. And finally, we can spider the application again, once more so that we can
enter the we can essentially process the strings that we that we just entered in terms of the user
name, so I'm going to right click and spider this branch. Okay, so it's going to start spidering.
And if we look at the spider, you can see that the the spidering is complete. And you can essentially
clear the cues if you want to clear the clear them like so. And you can keep on running it depending
on what you want to do. Okay, so I'm just going to pause it. And now we have essentially
spidered the web application. And you might be asking, well, I've seen a few reference sites,
that's not helping much, you know, we don't need twitter.com or you know, sizzle js, this might
give us a basic idea of what types of sites are linked to to the web application. But in reality,
you can see we have hackers.org not not very important information at all. Now, what if
we click on the Mattila day folder? Oh, look at that. That's really interesting. Now that is very,
very important. What has happened here is it's given us the structure of the web application,
this is vitally important. All right now, again, as I'm saying, you can look at how the website
or the web application is structured. So in documentation, you can see you can go ahead
and read the documentation, you can look at the images that the website has the styles,
so you can inspect the entire site and understand what exactly is going on here or get an idea of
what the person who developed the website was thinking. And then finally, out of experience,
or as we'll be looking at out of knowledge, you can actually understand how to exploit the system.
And that we will be talking about discovering hidden files, hidden files, like admin pages,
login pages, you know, that really juicy stuff. And we'll be talking about that in the next video.
And that's because that sweet Community Edition does not support or have allow you to use that
feature. So what I'm going to do in the next video, I'm going to be using burp suite Pro,
and also show you an alternative program. I'm sure you've heard of it. That also works on Windows.
Of course, that's how it works on Windows. But I'm not really a Windows fan when it comes down
to penetration testing. So that being said, we have essentially spider the application we have
the structure of the web application. And now we need to look at something also very interesting
as we have already talked about it. Let me just complete. Let me just show you how to get rid of
all of these reference links and to essentially show the items in the scope only. So what you
can do is just click on filter right here, this little bar here is the filter bar. So click on it,
and it's going to show you bring up this smaller window and you want to focus on the filter by
request type and make sure you check show only in scope items. This will essentially filter all the
results to show you only links or resources or files that are within the scope. So once that's
done, just click back on the filter. And as you can see it has got rid of all the junk that you do
not need whatsoever. And now you can essentially look at the, the requests and the responses and
analyze them accurately defined to your scope. And this will essentially, it will stop confusing you,
I've seen many beginners make this mistake where they don't define the scope. They do not know
what the target is, and they're getting links that are not even relate to the website that they're,
they're trying to perform the penetration test on. Now, since you know this knowledge, this
will help you get a solid foundation. And again, you can start logging out of skip out of scope
proxy traffic when you want. Again, that's very nice that they add that button right over there.
Alright, so now you only have the files that you require, or the files that you're currently
performing the penetration test only. Now I know this, this video was slightly, there was not a
lot of action. But again, it is very important that you get this in the next video, we'll be
looking at how to how to discover hidden files or files in general that you are not supposed to
find. Okay. And that can be done by right clicking and going into engagement tools. As you can see,
it is defined to the professional version of burp suite. And we will be going into discover content
where I'll be explaining to you how to find things like the login page or the configuration
page. Some things that web developers, you know, actually just may try to hide them. But if it's
actually found, can really exploit the website or can lead to the exploitation of the website.
We're going to start looking at how to discover hidden files. But before that, I just want to take
you through a few things. Alright, so let's start off with what OS base or o w SP. Alright, so what
does that mean? Well, essentially what it means, or what it stands for is the open web application
security project. Alright, and its goal. Well, essentially, it is a nonprofit organization
whose goal is focused on improving the security of software. All right, so its job is to improve the
security of software. Now this project, the O w SP, or the open web application security project,
created a tool called as the Zed attack proxy. Or as you know, it the zap, many people like calling
it zap. And I'm sure most of you have heard of it. And you might have been, you might be
leaning towards burp suite a little bit more. But I can guarantee you that zap is one of my favorite
tools. And I use it because firstly, it's free. And for the people like for the students I teach,
I usually tell them to start with zap because if you get zap, you'll automatically get burp suite.
And you only need burp suite when you're moving into an enterprise environment where you know,
burpsuite is the recommended tool. And it is the tool that you must use to adhere to certain rules
and ethics. That being said zap is a fantastic tool. It's absolutely free. As you can see the
old w SP Zed attack proxy proxy, which is, you know, abbreviated as zap is one of the
world's most popular free security tools and is actively maintained by hundreds of international
volunteers, right. So it helps you find security vulnerabilities in your web applications while
you're developing and testing applications. So again, if you're a web application developer,
this is also a fantastic tool for you. And as I said, it's going to be a fantastic alternative
to do burp suite. All right now that's not to say that burp is bad. burp is more of a
enterprise an enterprise developed software. As I've mentioned in the for the first video
of this series, burp is focused on professionals. Now that's not to say that zap isn't, but you'll
get the idea. Alright, so I'm going to be making a separate video on installing zap and I'm going
to make a video on how to get accustomed to the interface because it is slightly different. And
the language or English used for the interface is again very well obviously very different but it is
quite different. So again, getting used to it was also something that is quite helpful because we'll
be needing some of the enterprise features and on only a tool like zap will be a great alternative.
However, if you do have burp suite Pro, go ahead, it will it will just be the same thing. As I
mentioned in the previous video, it's really very easy to to follow up where we left. Okay,
that being said, it runs on the same network proxy, it runs on the localhost. So make sure
you're running it on the localhost and on port 8080. I'll be showing you how to change the port
if you so feel you want to. That's also another great thing about us as AP is it allows you to
change the proxies. So I have Mattila day opened up here and it is again running on my Metasploit
able to virtual machine and it's running on the IP address my local IP address 190
2.1 68 point 1.104 as you can see Mattila day. Alright, so that's working perfectly. So let me
just leave those other tabs open because again, there's no there's no real harm. Okay, so, again,
you can configure the material at a security level if that's what you want, you know to do to make
things harder. But I'm just going to be showing you the focus of this video, which is how to find
hidden files. Now, you might be asking, why do we need to find hidden files? Or why do we need
to discover these hidden files or hidden files? Firstly, are the files like admin login pages,
you know, maybe a robots dot txt, but that's not really something that's hidden nowadays. It could
be a txt containing maybe usernames, you know, something really weird, or, you know, pardon
my English or pardon my language, something dumb that the web developers left behind, or, you know,
just not configured correctly. And you'll see what I mean in a few seconds. All right. So again,
these are the files that are hidden, and you will not find them after spidering,
your web application or website. Alright, so let's get started with zap. As you can see, I have the
logo right here on my it's added to my favorites, let me just launch it, give it a few seconds, and
it should start up. There we are, the zap, give it a few seconds again, and make sure you update it
usually the updates for the modules very, very regularly. So make sure you update them to the
latest version, as they improve the speed and so on and so forth. Alright, so it's going to prompt
you here, do you want to persist the substation, that means Do you want to save this app session,
I don't, I do not want to persist the session at this moment in time. So I'm going to start. Again,
don't worry, if you're not familiar with the interface, I'll be going through it in another
video because it deserves Now you might be a little bit overwhelmed. But do not worry, do
not stop going to you know URLs to attack that may seem really really tempting. But again, you know,
let's take it nice and easy. So let's talk about the proxy, how to change the proxies. So to do
that, you can go into your cog right here, as you can see, or you can go into tools and go
into options. Alright, but I like going into this little cog here. And once you press on, once you
click on the cog, let me just enlarge that, you will see that you have this huge menu. And again,
as I said, zap is a really advanced tool, and in some cases can totally replace burp suite. Now,
looking at the proxies, you want to go for the local proxies right here. It's obviously
starting with L. So local proxies, and make sure that the address is hosted on localhost.
And you can change the port if you're using burp suite and stuff, like you're just using both the
applications at the same time, or you're running something on localhost already. So you can change
it to something like 8081, whatever you feel is comfortable for you. Okay, so that's how to
change your proxies. And if you're running the ad net, you can also go check this and that you
should be good there, if you don't find that the proxy is working. So just hit OK. Alright, now,
you see that there is no draya We are not going to be looking at intercepting right now, but we will
be looking at that in a few in probably the next videos, the advanced videos with SAP. Alright,
so let me just reload the material a page. And as you can see, I'm running the proxy. So I'm
just going to reload the page. And as you can see, we are not intercepting actively. So Whoa,
what's this? Well, we got some files here. Let me just reload the page one more time. And there we
are, we are getting some results. So we get the IP 190 2.1 68 point 1.14. That's the server and if we
just click on this drop down here, we get request. So you can analyze the get request. If that's what
you want, you can right click, and then analyze. All right now will we not be looking at that right
now because I want to focus on finding the or discovering the hidden files. So what we'll do
is we want to click on the utility folder. Now one of the great things I like about zap is it already
gives you the file structure or the website structure immediately here. Alright, so again,
so you have your images folder, which has it, the images there, you have JavaScript styles,
and your all the resources in regards to the website that it could find naturally. Alright.
So if we, if we just look at the bottom here, you can see that it it's showing you a timestamp with
the method that the URL, and it gives you the the code which means the pages in this case,
the 200 code means the page was found, you have the reason you have the RTT, the size, the alert,
as you can see, it's telling us we have a high alert here. Now don't worry about that. Again,
these are things that you know will be will really be tempting, but again, let's take it slow.
Alright, so the first thing you want to do or you need to do is to right click here, and you want to
go to attack and hit spider. Alright, so we want to spider the website or the web application and
start scan Do not touch anything here. Just make sure it's using the appropriate server address
and just hit scan. Right now it's going to spider the entire web application and it's going to give
you a little progress bar here. You can pause it or stop it which is also great to see at the
bottom you should have also noticed that you have your tabs here that work really really well. And
as you can see the the website now is completely spidered. And if we just check all the files that
we can find now you can see that we have some more JavaScript files. And essentially what's happened
here is the entire site has been, has been spidered. Okay, now we already did this with burp.
And the you know, you've you're probably really bored of this right now. So what we're going to do
now is we need to, we need to start discovering the hidden content, right. So let me just close
all of this up. There we are. Fantastic. Now, let me just open that up. And let's go to Mattel
today. Oops, my bad Sorry about that, guys. And we want to right click on Mattila day,
and you want to go to attack and you want to go to first browse directory and children that's very
important. First browse directory will not display everything, we'll also be looking at fuzzing,
but that's for later. Alright, so you want to make sure you hit forced browse directory, just click
on that. And it's going to open up this tab here. So you can see we are despite the tab open, which
you can close read if you're not using it, which is also great. I really like the management of
zap, you then have output for your outputs alerts. As you can see, you have some alerts here that
will alert you on some potential vulnerabilities. So for example, APPLICATION ERROR, disclose,
you have some cookies, a noise GTP flag. So again, awesome stuff there. We have to get requests,
all that good stuff, which is again focused on a different type of attack. And as you can see, by
default, we've got the robots. txt here, which you can analyze if you want to, by clicking and going
ahead and doing that. So you can copy the URL to the browser. So again, copy the URL to clipboard,
alright, and if we just try and explore this, let me just paste and go here. As you can see,
we're for some reason, we're not actually getting robots to txt. Let me use the motility date. Till
today, or actually, you know what, let's not do that right now, because I really want to stay
on topic here. So I'm just gonna go back into that. Again, I always love going off topic,
fourth topic for some reason. Okay, so make sure you click on motility and you want to right click
on it. And now Oh, sorry, we already did the first browser, right click, go to attack and
first browse, directory and children. Alright, now it's going to open up this tab here. And
it's going to, it's going to make you choose the site. As you can see, you have your site IP here.
Now you need to select the default directory list to it's going to use this list here, this
default list that comes already with zap. And now it's going to try and use it in a sort of a brute
force way to try and detect the hidden files and folders. And once it gets the result, it's going
to enumerate them. Okay, so now you want to right click again on it, after you've selected the list
and hit attack. And you want to go to force browse directory and children. And once you hit that,
it's going to start the process. Now again, this is going to take a long, while not a long time,
depending on this the size of the website, if the site is huge, then again, it's gonna
take a while. And as you can see, immediately we're getting some submitted files. So let's,
let's wait for this call to complete. And I know motility has some very, very interesting files
here that I'm sure will be happy to get. Alright, so just let it go through this. As you can see,
you can check the progress as you're going here. And again, the the if you look at the status code,
you can see 200 means the pages were found. So you can just go ahead and look for things that
are irregular. And I'm sure we can find something here that we haven't found before. Or you can
look at the at the file form the website directory here. So um, Mattila day, let's see if we can find
something that is really, really interesting year. So we have the includes we have the get index of
PHP, we get regressed, sorry for the index dot o we have something interesting here we have a
notes folder. Aha, now we're talking now this is where stuff gets really exciting. Alright,
so we have whoops, where'd it go? There we are. So in notes, we have some very interesting files
in notes. So we have a get passwords. Now what happens? What's this about? Alright,
so what if what what if we just open this URL in the browser? Alright, so let me just try and
open that in Firefox, I just want to see what it's going to be all about. So hopefully, it's
opened up in my browser. If it's not, I'll have to copy the URL, probably because I haven't set any,
any default. Alright, so copy URLs to clipboard. And let me just paste that in there, paste and go.
There we are Mattila day and passwords. Alright, so you can see that this folder or this file was
hidden. And we have an interesting txt file here, which again is quite scary to go we did open
Firefox. Well, don't doesn't look like we need that instance. So getting back to the topic here,
for some reason, process unexpectedly closed with. Alright, so that looks like we have a
Java error there. So let me just go back in over here. So again, we found an accounts dot txt file,
what could that be? be caring. Let's click on that. Oh boy. So again, we have accounts here.
And well, I'm pretty sure you will know what this means. This is just bad practice from the website
developer, where he wrote notes. And essentially, these are the accounts. Now let's see what else we
can find. Let's see accounts. Nothing interesting in accounts, because we now have the account. So
that makes our brute force much easier. You then have, let's see if we can find any passwords if
they were ever saved here. I'm pretty sure they are not. But we can also look for some interesting
files here. That can be really interesting. Or you can look at the sitemap if you want to. So let's
also copy that. Let's see if it gives us access to the sitemap also very, very important stuff there.
Oh, yeah, so the sitemap, for some reason, we were not able to process it. Alright, let's look for
some other files here. Let me just open up Mattila day again. So we have the get images. Let's see if
we run the get images. Let's see what images we can get. Again, I'm going pretty amateurish on
this. I'm just clicking on everything. But I'm just trying to show you the amount of files that
you can find, as you can see, immediately, you can find that the refresh button, you know all
the icons related to the website. You have the I hack banner. Oh, yeah, hackers for charity,
man. So I'm talking about YouTube. Oh my god, what an old logo that is the older BSP logo. Pretty
cool. Pretty cool. And yeah, so you get the idea. So this is how you actually go through website
and find files that could contain you know, stuff that is quite interesting, to be honest. So let's
see what else we can find. I'm just going to go to one more resource here that we've found, oh,
we have to get register out. Now. That's what I'm talking about copy URL to clipboard. It's actually
it's actually quite fun. This why bug bounty hunting is? Oh, yeah. Now this is what I'm told
we can actually register. We can actually register ourselves on the website. Now again, looking at
the website from here, it doesn't look like we can. Can we even register on this website? Not
sure we can. For some reason, it's not actually letting me scroll to the top. But hey, I don't
really know what's going on there. So let's see if we, yeah, we can definitely log in render and
register. Sorry about that. We can register there. So yes, it is the register. It does exist. So that
wasn't actually hidden. But it was hidden. It was hidden to the women when we spidered the website.
So that means indeed, it was hidden, for obvious reasons. Because the brute force for example,
if you find the login, which is again here, and again, if this is hidden, you can imagine
the the damage that you can do so again, you can log in from there. Set up database, whoo. Now,
that's interesting. For some reason, it's not letting me copy. Alright, so looks like we got
set up database here. So yeah, we can Okay, I do not want to manually edit the request. No,
I do not want to manually edit the request. For some reason my keyboard is being pressed here.
While that's we admin, copy heroes to clipboard. All right, sorry about that my spacebar was being
mashed on by my tablet in front of me. Right. So let me just there we are on. So no PHP MySQL
errors, were resetting. So essentially reset the database, and you can see the damage that this can
do. So again, that is some good stuff that you can have fun with, when especially with Mattila day,
you can increase the security and find what other files you can, you can find, you know, with zap,
again, zap is a fantastic alternative that you can use. If you know if you're not ready to invest in
burp suite, that's totally fine. I used zap for I think about three years, especially since 2014.
I think I used it in till about I think 2016 or 17. I'm not too sure. And it worked great for me,
I really enjoyed it. And I'm just getting back to I'm just remembering all the tools used to work,
it was actually quite a user intuitive interface. Because I just remember right
clicking means you can copy the URL, you can inspect it, you can change the request,
you can attack all that good stuff. And you know, it's sorted out really, really well. Alright,
and you can look at the requests here, you can change them to whatever you want,
and then send them you can intercept them. So it essentially does whatever but a suite does.
We're going to be looking at web application firewalls, or waafs, as they're called. Now,
this may be a new term for you and do not worry. This is now when we move into a more professional
level. And again, this is what I've been talking about is most people out there or most documented
documentation out there won't cover the most important industry standards. You know, now when
I'm talking about web application firewalls, what I mean is, is these are the protection or these
are the mitigation procedures. put in place to protect a web application from attacks, obviously
now as a penetration tester, or if you're looking at it from a white hat, or a black hat
perspective, from wider perspective, it's always important to have a web application firewall. And
I'll probably make another video showing you how to set it up, it's really easy, and it's free,
and it will probably removed about 20% of attacks. Okay, so that's if you're a white hat. Now,
if you're a black hat, and you're targeting, or you're performing a penetration test legally on
a website or web application, we usually what the employer will tell you is they'll give you
a scope of the project. And again, they might give you the source code, etc, etc, you get the idea,
you have your white box, testing, black box and gray box. But coming back to the firewall,
most of them will know that there is a firewall. And that's because the person who set the website
up for them in terms of hosting, or the web application for them, will in most cases,
on a professional level, have a web application firewall. Now you might be a bit confused. And
you might be saying, Well, why is this important when performing a penetration test? Well, this
is important because firstly, it's something that most pen testers overlook. And if you know this,
you've got an ace up your sleeve. Alright, so essentially, what's happening is if it's being
used, if a web application firewall is being used, you obviously first need to detect it.
And I'm going to show you how to detect it in this video using a special tool that I don't
think you've ever heard of. But it's also industry standard. So this is a real secret, I don't know,
for some reason, it's not just, it's something that just hasn't caught up yet. But hopefully,
after this video, you'll know about it. Alright, so essentially, the purpose of a web application
firewall is it protects the web application, you know, from a firewall point of view in the sense
that it blocks attacks, as one would expect them to come. Now what does this mean for you? Well,
this means that you will need to, you will need to manipulate any type of data that is
going to be encoded, alright. So what this means is, if you're, if you're performing a
penetration test that involves you manipulating data and sending it back to the web application,
then you need to encode it in a specific way to bypass the firewall. Otherwise, it will be blocked
by the firewall. And I'm sure most of you have actually done this before. If you're just amateur
penetration testers, and you've just begun, you'll find that for some reason, your requests aren't
being processed. And that's because they've, there is a firewall set up to prevent these malicious
requests from being processed. Okay, so again, web application firewall is really, really important.
Now, looking at the tool we'll be using, the tool has actually a very, very funny name you for some
of you might find it hilarious, it is called wolf wolf. Now for those of you who have heard of it,
you pretty much already know how to detect a web application firewall, but it's really very, very
simple. Alright, so just open up your terminal. And what you want to do is you want to type in
wolf wolf. Alright, so this is how it is going to be spelt. So it's worth Wolf with a tooth with
two zeros. And the syntax is pretty simple. If I just hit enter, as you can see, we're forth a web
application firewall detection tool. Alright, so credit go to the author, it's actually it's a tool
that's been there since the, I think almost the last version of backtrack and the first version
of Kali. So again, quite an old tool, I when I say old, I mean, you know, I mean that with respect,
given the fact that it's a really, really useful and I've used it a lot because it saves you a lot
of time. And what I'm talking about is, so let's say we want to scan a website, okay. In this case,
I have my WordPress server running here. And as you can see, it's the site is being hosted on
190 2.1 68 point 1.11. Alright, so I have that IP opened up in my browser. And as you can see, it's
a WordPress site. And this site is vulnerable. And this is what we're going to be performing
later on the penetration tests on. But for now, we want to find out whether it has a firewall. Now by
default, I know it doesn't have a firewall. But let's see what we're for Fidelis, alright, so the
syntax is very simple. As you can see, you just type in wolf Wolf, and you enter your URL or your
URL, so you can enter as many as you like. Okay, so I'll give you an example of how to go about it,
make sure you enter your HTTP or HTTPS protocol. And we just, let's try that out. So Wolf, Wolf,
and we specify our protocol HTTP in this case, and the IP address 190 2.1 68 point 1.11. All right,
now in this case, I'm pretty sure that it won't detect any web application firewall.
So let me just hit Enter. And as you can see, no web application firewall detected by the
generic detection. Alright, now this is very, very advanced. And this tool is an industry
standard. And if it does tell you that there is no web application firewall, then by all means,
I can guarantee that it will it does not have a firewall. Now let's look at one of my sites
that I currently own. It's a site that I use. It's actually My web development company that obviously
we use for web development now I've predicted this site with a web application firewall provided by
CloudFlare. Now, for those of you who are web developers, and when you're performing your
hosting, you know that using CloudFlare is awesome because it allows you to optimize your site for
speed. It allows you to purchase assets and make your site faster, protected, and again, protected
from DDoS attacks, etc, etc, all the good stuff. So let's see if it will actually detect this. So
I'm going to type in wolf wolf. I know that name is really, really funny. The protocol is HTTPS,
https like so and I'm going to specify the site which is Elgon studios.com. Alright,
Elgon studios.com. And if I enter, as you can see, it's going to start checking the site, give
it a few seconds, it shouldn't take any much. You know, a lot of time, and as you can see the site,
Elgon studios.com is behind CloudFlare. Right now, what this means is that most of the most of the
attacks that involve manipulation of data will be in some way blocked. And you know, you won't
get your response back the way you wanted it. And the render wouldn't be the same. Right now. Again,
as you can see, it detected that it is behind a web application firewall. Now the next step
is how to encode these, how to encode encode your your requests that you're going to be sending to
the web application. And that's what we'll be looking at as we increase the security level,
using the the dam vulnerable web application. Alright, so I thought, this is something that
I really need to share with you, again, it's going to really help you. And I promise you, this
is something that, you know, if you go for a job interview, or you're performing a penetration test
for a company, this is something that most of the network or systems administrators are very keen
on, they want to know whether you really know your stuff, and whether you're really up to date with
how to detect, first of all, because information gathering is really important. And as you can see,
this tool is fantastic. And once you know there's a firewall, you then have a better idea of how to
target and you won't be wasting time. Again, that's something that most of the amateurs or
beginners do. They waste a lot of time trying different commands that they've seen, but they
find the date and they see that it doesn't work. And they're like, how is this possible? Am I doing
something wrong? The truth is, the web application is probably well protected. So again, you know,
do not use this for any malicious purposes. Again, this is simply an information gathering tool.
I'm going to be showing you how to use der Buster to discover directories and files on a website or
a web application. You might be asking yourself, what is der Buster? Or if you haven't heard of
der buster, let me explain it to you. Alright, so the airburst is essentially a tool that was
developed by OS, the open web application security project, and essentially uses a brute forcing to
find commonly used directories and file names on servers. Alright, so this tool is extremely
useful for those of you who are doing CTF, for those of you who are bug bounty hunters, because
essentially, it allows you to understand the structure of a web web application or a website in
terms of the files and directories and how they're structured. Alright, so why is this important?
Well, this is important because this will help us understand how we can attack a site or what type
of attack vectors we can, we can we can find, you know, so for example, if I the web application,
and I'm going to demonstrate that right now, and I scanned it with the bust, and we found some
hidden directories and hidden files, we can use these as attack vectors. Alright, so as I said,
it also allows you to find hidden directories or files that are hidden from the public. So this
can also lead you to, to finding additional resources that could have been hidden away
by the devs that like for example, admin pages, etc, etc. Alright, so how does it work? Well,
really simply, once you start up there, Buster, and again, as I mentioned, it uses brute forcing
so I'll explain where wordless come into play. So you open it up and you select the URL of the
web application or the website and you specify the port The port is is the is definitely going
to be HTTP sewed a the a port 80 or Port 443. And then you select the word list now, in this case,
Cali annex already has a dub dub Buster word list that that are designed, it has three of them that
are designed for different types of scenarios. And I'll explain them as we move along. All right,
and essentially how it works is once you start the brute force attack, it will send HTTP GET
requests, and it will wait for the response from the server or the web, the web application. If
it gets a 200 response. That means that yes, that directory exists. Alright, if it gets if it gets a
bad response, meaning like 400 or four or three, meaning no access, then it'll it will it will
know that that directory of file doesn't exist. So it's essentially testing directories on the server
against This, this word list. So it will check, for example, is there a temp folder, if it sends
a temp request to the server, it gets a response, a positive response, then it knows it's there,
and then it will enumerate them. Alright, so let's start off really, really simply. So I'm on Cali
the next, I have the OS, broken web application, right here. And I'm going to be demonstrating two
scenarios. So you can see I'm running that here. And that has a lot of vulnerable web
applications. But the whole idea is to demonstrate how directories can be found. Alright, and why
this is extremely important, especially for a web application penetration tester. Alright, so
I'm gonna pull up Firefox. And as you can see, you have the open web application project right here,
the OS B web, as they call it, and it has plenty of ways of me testing this. But what if I was to
just test the entire server? Alright, so this is a web server. What if I was to test the entire web
so well, I'm guessing that there going to be a lot of files and directories. So what we can do is,
we can start off with a perfect example of how this will work is let's say you're targeting a
WordPress site. So I'm going to open up the broken WordPress. Now, of course, this is an very old
one, and we're not really exploiting anything. But by using this example, it will let us understand
how we can enumerate the different directories and folders, you know, on this WordPress installation,
or if you are target targeting a WordPress site, this is the way you do it. So I'm going
to copy the URL with the with the directory right here. So it we know it's in the WordPress folder,
because that is the root directory of the of the web server and we're selecting the WordPress
installation. But for the website, you will select the URL. Alright. And that's for the port,
we know that this is the default HTTP port, which means it's Port 80. Alright, so I have doorbuster.
Right here, if you can't find it, just you can use the start menu and type in der buster, it's going
to be like so just this click on it, and give it a few seconds to start up. So again, it was designed
by the OS team. So it works really, really well. And again, this is something that I'm sure if you
if you are a web application penetration tester, or you do do the CTF challenges, then you will,
you'll know that use this tool a lot. Alright, so we in here, we have the target URL, and that will
we will paste it Alright, so we can paste it right here. So Ctrl V, and that is the URL. Now in the
work method, if you want to, if you want the scan to be faster, you can use the GET requests, but
what we can do is auto switch them from the head and get and that will give us a more robust or a
more accurate response rate. Alright, so in terms of the number of days, this is how fast you want,
you want the scan or the brute force to be, so the faster the better depending on your hardware. And
of course, you don't want to overload the server, so I'm just going to go hit click on Go faster,
that's probably works the best for me. But if you wanted to run faster, then that means it's gonna,
it's gonna have multiple requests and threads being sent from your computer. Alright,
so I like keeping it at just 200 threads, which is go faster. And because I'm testing my own web
server, I can, you know, I can pretty much increase it to whatever I want. So usually,
if you're talking about a bigger server or a bigger web application, then it doesn't really
matter how many requests or many threads you use, it will not really affect the performance of the
web server. But if I was to run it at maybe a maximum speed, you'd see that the web server
would be lagging out, you know, out of the amount of requests that are being sent. Because you know,
you have to understand it from a fundamental point of view, we are requesting different web pages,
and the server has to process them. So if the if the if the server is not running on on, you know,
good resources, like it's running on one gigabyte of RAM, it's very easy to make it lag out,
and to actually cause some sort of a denial of service just because of the amount of requests.
But in this case, we are performing it you know, with with an ethical perspective. So now,
you want to select a list based brute force or you can use a pure brute force. But I don't recommend
that that doesn't really work. And you now need to select your word list your doorbuster word list.
Now by default on Kali Linux and on paradise, these are found in the user share folder on the
under word list. And you can find the doorbuster word list right there. So I'm going to show you
that right now. So I'm going to browse, I'm going to go to my root and I'm going to go into user
and I'm going to go into share. And let's go into Word Lists here. Let's see if I can find it. It's
obviously with a W. Where it Where is it? Let's see. Let's see. Let's see where is wordless story
if I can see this. Yeah, there we are. Sorry about that. wordlist and you now want to go into der
buster. Alright, so there is going to be a folder called der buster. And now you might be a little
bit confused. Well, really, you don't need to need me to be confused. That's why I'm here. So as a
beginner you might be wondering like which one is better. Now as an advanced penetration test,
I know which one is the best in Most cases, it's going to be the medium the directory list
2.3 medium dot txt. Now, if you're scanning a very small web application that that's not that really
complex, like a simple HTML site, you know, HTML, CSS, whatever you want to call it, then I would
recommend the smaller one. But if you're scanning a big site, like a WordPress installation,
or a Joomla installation, then you should use the medium one, this will work 99% of the time unless
your your, your requests are being blocked by either a web application firewall or by the,
the host. So I'm just going to select list. Alright. And now in terms of these other options,
you can see it's, it's going to essentially brute force brute force the directories,
the files, it's going to be recursive, which is great. And the directory, you must specify the
directory if it is if you are trying to perform a scan that is directory sensitive. Alright,
and standard start point, just leave it like that. And you now want to hit start. Alright,
so once you start is going to start brute forcing the web server against, it's going to start
sending the request. And if it gets the responses, the positive responses is going to, it's going to
understand that yes, that directory does exist. Now you can see we have a response that is being
sent here. And it's going to tell tell you that it is unable to determine a consistent failed
response, which means some directories and files are being you're getting a negative or you're
getting a no access response, meaning that that directory doesn't exist. So what you can do is
just hit Cancel to these ones in it Yes. And it's going to continue scanning the other ones. Now of
course down here you can see since it's performing a brute force, you can look at the current speed,
which varies dependent on the amount of directories, the average speed, and it will
tell you the total amount of requests done out of the amount that could be done depending on on the
word list that you have selected. And finally, you have the time to finish. Now, of course, this will
vary depending on a lot of factors. But mostly it depends on the speed of the scan that you've
selected, and the and the word list. So you have your scan information here, it's going to tell you
what folders and files it's testing. And in here, you can see the results in terms of directories
and files that it was able to find. And in the results, this is going to give you the directory
structure as to how files and folders are being structured on the web application. Now by default,
right now, you can see the amount of the files and folders that it has found are,
for example, the WordPress register dot php. So if we open that, if you right click on it,
you can open it in the URL, or you can view the response that it gave. And you can copy it,
you understand you get the basic functionality here. And then you can open it in your browser.
So again, you see that we are finding files that we otherwise wouldn't have known existed. Now,
of course, for a default WordPress installation, you would have guessed that this does exist. But
remember, most people are for volken, for most other installations on configured figurations,
this can be a great way of finding files and folders that you didn't know existed. And again,
discovering them is very, very important. And this can give you different attack vectors. So
for example, if I went to the admin dot php, and it forced me to log in, that might be a good place
to start brute forcing, if I had credentials, if not, you can choose Select another attack vector.
So let me just move back here you can see we have the register page here, which we just clicked on.
Let's look at the WordPress login dot php. So I'm gonna open that up in the browser. Now you
can see the server is not responding. And that's another point that I wanted to point out. If you
want to be as you know, right now we are being as promiscuous as possible. Because we it's
not really a web application that is delivering service to other people. But because it's hosted
on my local area network. So in this case, you can do a performing a type of denial of service.
And that's because the server is located very, very minimal resources to this virtual machine.
So that's why it's kind of lagging out. Alright, so that's something to take into consideration.
Now if I was to, to pause the attack, like so if I was to just pause it, remember, you can pause it,
and you can stop it. And let me just go back here. And let's see if we can reload these pages,
they should be able to, to be reloaded quick enough. Let me let me just load that up. And
we can close this one. Let's see if the WordPress register page does open up. If this virtual, yeah,
there we are. So you can see even though this is a very old WordPress installation, that we
were causing it to lag out. So always keep that in mind that the amount of threads that you say can
affect the performance of the website of or of the web application and you don't want to cause any
any impact to customers if you're performing the test on a real world working web application or
website. Alright, just something you might want to take into consideration. So we're going to resume
it and of course I'm not going to expect to find anything we add here. Although this WordPress
installation is designed to be vulnerable. So you can also change the number of threads
running right here. So if I wanted to run, you know, maybe on 10 threads, which is quite slow,
that means you will get, the enumeration process will take longer. So it's all about balancing your
resources and understanding what you're trying to look for. And of course, this can be a very,
very useful tool. When doing bug bounties, or, or CTF for that matter, especially hack the box,
we are going to be looking at something that is extremely important and something that should be
understood completely, and that is cross site scripting. Alright, now before we get started,
I'm just going to explain what we're going to be looking at explain what we're going to be
looking at in this video, we're going to start off with explaining what cross site scripting is,
I'm going to be showing you the environment that we'll be using for testing any of these,
any of these attacks just because they allow us to illustrate or they allow me to explain
how everything works, because that's the most important thing for me is that you understand
what you're you're listening to, and you have a good representation of what's going on. Alright,
so I'll be explaining stored. I'll be explaining the reflected stored and Dom cross site scripting.
Alright, so let's get started with me explaining what environment I'm currently running. So you
can see that I'm running Kali Linux right now. But I am going to be using the OS broken web
applications project. So I'll have this in the description section, it is essentially
a virtual machine, that you can easily just run on VirtualBox or VMware. I'm currently running
it here. As you can see, I just got the local IP, it's 190 2.1 68 point 1.111. All right, so
I have that running. And I'm running this on Kali Linux, and I already have opened up the URL in my
browser. So you can see from here, I've opened up v whap. And I've opened up webgoat, because
that's what I'm going to be using to explain each of these cross site scripting attacks. So if I
was to do that false to just open up 190 2.1 68 point 1.11, yours could be different, it should
be different. Depending on your IP configuration, and subnet, then it'll take you to the OS, b,
w A, or the OS broken web applications project. The latest version, as of recording this video
is version 1.2. So we will be using webgoat and B web, or the broken web application project for for
this demonstration. So the default credentials for webgoat are going to be guest for the username and
guest for the password. And for B whap. It should give you the prompt right over there. I think it's
going to be bug app or something like that. But irregardless, it will tell you what it is. All
right. So make sure you open that up, and you have that all set up. So I've logged in to be web and
I have a web goat started up right here. Alright, so let me close that up. And we are ready to go.
Now before we even move on into performing these attacks, it's very important to understand what's
going on here with with cross site scripting, what it is how it works. And what are you exactly
taking advantage of right now, this is where a lot of people make mistakes. And if you want to be a
successful web application penetration tester, you need to understand, you know, from a fundamental
level, what's going on here. Alright, so let's get started. What is cross site scripting? Well,
simply put it is the process of injecting a script into a into the parameter in a URL to attack
a user of the site or to potentially attack the server side of the website or the web application,
right? So essentially, is the inject the injection of a script into the parameter of
a URL. All right, that's essentially what it is. Now, of course, this may be quite confusing, but
don't worry, I'll explain what's going on here. So let's start off with with, first of all explaining
the three types of cross site scripting. All right, the first one is reflected and then
we have stored and Dom. So with reflected what's happening here is the data is inputted and then,
you know, reflected directly back back on the screen. So I'll explain this in a second. Alright,
so if we are to look at this from a fundamental perspective, I'll show you how to access this,
you know how to navigate the view up. Just give me a second, let me explain what's going on. So
essentially, what's happening with reflected cross site scripting is that the input is going to be
stored in the parameter of the URL. All right, and I'll explain how this differs with each type
of attack. Because many of you will point out and say, well, it's not only to do with parameters,
and don't worry, I'll explain all of this. Alright, so we can essentially manipulate the the
parameter of the URL, so that we can essentially run a script. Now what type of script we can run a
malicious script that is based on in JavaScript, and I'll explain that right now. So you can see
with our portal, you don't want to touch anything here, you can set the security level. But for now,
I recommend setting it to lope. Not that that's going to hurt anyone's ego. Because remember,
you have to be humbled to begin, and you need to understand what's going on first. So we will open
up the Jews, the bugs section here, and we want to go down into cross site scripting. And we want
to go into reflected which essentially deals with the get the get request. So we're going to start
off with that. And this will really make you understand what's going on here. So if I click
on that, and I just hit hack. Alright, so now it's going to give us a prompt here. And you might be
asking, Well, what what do you mean, what exactly is going on, if I was to not enter any details
into the, you know, into these fields, right here. So for example, you can see I just had a
suggestion there, that's because I was testing it out. But if I was to hit go, you can see that in
the URL, we do have the input here. So you can see the values can be edited directly into the form.
So you can see first name has no value. And then we have the last name, which again has no value,
and you can see that it is submitting a form. So what we can do is run some JavaScript code
in here. And the most common way of explaining what's going on here, of course, not running a
very malicious code right now, it's essentially explaining and demonstrating that it does work is
I can run a piece of code here. Now, of course, when you put this into a practical perspective,
many sites are going to filter the content that you can enter in these fields, all these forms,
and will essentially will not allow you to run JavaScript code and you know, obviously,
to protect, protect the site from these type of attacks. But what you can do is encapsulated to
encode it in a different type of language. Or, as I said, I'll show y'all everything,
or how all of this works. So this right, right now, being the current security level, as low,
we are a lot a lot essentially encode, it will not verify or validate what we're entering in
here what input is being given. So if we were to type in a script here, so we can say script,
and you can see the recommendation there script, that's mine. So if I was to type in alert, and
this is JavaScript, so I'm pretty, I'm pretty sure you can you know what's going on. So we can say,
Hello world. This is an example of reflected accesses, or cross site scripting, and we can
close that operate now. And then we need to close the script. So we can do that in the next field or
the next parameter. Most people like doing it from the start. But this is just to show you how robust
this can be. So I type in I close the script and hit go. And as you can see, it gives us the alert,
which is what we and we which is what we used as a form of, of me showing you that it does
work and it will be processed, the input will be processed and will be sent back to you, you being
the client. And we can just hit OK. And that was an example of reflected excess cross cross site
scripting, using the get method. Now of course we can, I can replicate this many, many times
using the other types of cross site scripting, for example, with the post, etc, etc. We'll be looking
at all of that. But for now we need to understand what's going on here. Now next, we need to look
at stored cross site scripting, this is probably my favorite because of the potential that it does
have. Alright, so let's go into the juicy bug menu here. And we want to go into cross site scripting,
and we want to go we want to go for the blog, cross site scripting stored cross site scripting,
and we're gonna select blog, and I'll explain why in a second. Alright, so first,
let me explain what stored cross site scripting is. So essentially, with this with the cross site
scripting attacks, more specifically, these stored attacks, essentially, what's happening is you're
attacking the input. And you're essentially attacking the input that is to be stored or
you're attacking the data, or, essentially, I'll explain this really simply, so you're attacking
the input that is to be stored on a database. So what you're doing is you're essentially injecting
malicious code that will be saved into a database, or that is going to be saved by the server,
or the web application server. And then you can definitely you since it's being stored, you can
access it later on or other users can access it. And for example, if it's running malicious code,
it can trigger different things like opening the webcam of a user stealing different type of
information. I'm not going to go into what you can do with it, but you can really do a lot of stuff,
a lot of malicious stuff with code. Alright, so let me explain what's going on here. So with this
stored, cross site scripting, you can essentially inject malicious code into the database again,
that then that when accessed runs this malicious code. Alright, so if you can see
this is an example of a blog. Let me explain what I mean the best places to implement stored cross
site scripting is in places like means, you know forums. And again, as you can see write your blog
in the form of comments that you know, or pages that can be accessed later, or data that is being
stored in directly into the database, any database for that matter as long as it's being stored,
okay, so we can type in something like hello. And we can submit that to the database. And
you can see it's getting stored. And you have the different tables, you have the the number,
the owner, the date and the entry. So now we can also run a script in here. Alright, so what if we
were to enter Java scripts, and again, this data, given our security level is any of the data that
we're entering is not being validated. So you can essentially enter it raw. Now in reality,
if you go and try and enter a script in the native will not be accepted, because, again,
they're protecting their site against that. That's one way of mitigation, very basic,
I'm sure you know what I'm talking about. Alright, so enough of me rambling on. So if we are doing
enter the same script we entered, we are to say script. And we then say, alert, for example,
we can you can use any type of JavaScript code you want here, and you can experiment, you know,
you these web applications are there for you to experiment and test your skills out. So first
to say, Hello world. This is stored out stored cross site scripting, and we just close that up
there. And of course, we have to close the script, because we know that that will not execute if we
do not code it correctly. Okay, so now we can we can add that. And if I was to just hit submit,
right, now, you can see that it's going to store and with that being the latest blog post, you can
see it's going to tell you, it's going to execute the script. And it's going to say hello world.
This is stored cross site scripting. So an example of a blog, if you're to post this on a page or a,
you know, to make a blog post and inject this script in, anyone opens that page will essentially
run that malicious code. And whatever that code does, can then furthermore, you know, cause damage
to the user or to the server depending on what you want it to do. So it's all dependent on what the
attacker is to do. Remember what I told you in the first video of this series, it's all about
your mindset, and your your your willingness to break things and to find out what does and doesn't
work. Okay, so that was an example of stored cross site scripting. And as I've mentioned,
the most important thing to understand is this in this scenario, the data is not being validated if
it is being validated. And I'll show you that in a second. Or probably in the next set of videos,
we'll increase the security level, and I'll show you how to get you know past this, you can see
how things change as you move along in terms of security levels. So I was going to use the V whap.
This my first time using it. So I had to get a bit of an introduction through the documentation.
And I realize they don't have dumb cross site scripting. So I that's why I had to use webgoat.
They're the only ones I know who actually allow us to run it. So as zoomed in right now, by the way,
the credentials are guests for the username and guest for the password. So essentially,
I went through cross site scripting, and again, they didn't have the DOM in here, all they were
focusing on is stored and again, reflected. So I found it to be in the eye x or Ajax or whatever
you want to call it. And we have the the DOM based cross site scripting, let me explain why
it's in. This is based in Ajax security. This is because Dom cross site scripting focuses on
the client side. So any data or input that is entered, whether it be a malicious code, etc,
etc, is going to be processed by the client, not the server. So any of the attacks will be based,
of course, on the client. Now, let me explain what I mean. If I am to run remember, JavaScript,
server side, client side i x, for example. So if I am to run, for example, a JavaScript
code in this entry here, so script, and again, I type in alert, just being the example and I say,
Hello, let's keep that simple. And I close the script here, you can see that we will probably
not be left with anything will not get any result. That's because it's being processed by the client,
not by the server. So no, no result or no data will be reflected back to us. If it was, you know,
if it was reflected cross site, scripting it, the server processes it, and then is reflected
back to the client. So if I was to submit here, you can see that nothing happens here. And that
it is going to be taken as code. Now what if we were to enter or use a language that that
a client can understand? So let's say we want to say, let's see, HTML, whatever to use HTML,
so I can say in here, IMG, for example, that's a very This is the way we learned it. So IMG See,
and we don't have an image source. So we can leave that like that. And then we can use the on error,
in case we get an error of image which we will get because the image has no source on error, we can
say that is going to be, that is going to be equal to alert. And then the alert we can input in here,
we can say, Hello, whoops, hello world. And we can close that up. And once we have closed it,
you can see that we can, we can close that there. And there you are. So it is great to be processed
by the client, and you get the dialog box or the alert with the message Hello world. So you can
see that with Dom based cross site scripting, it is all being processed all the input, whether it
be malicious or not, is being processed by the client. And Ei x is one of the largest languages
that can be used. So you can also incorporate a x if you wanted to test it out. Remember,
it's all about experimentation and understanding, I hope that you're you've got an understanding of
what cross site scripting is, how it can be used to manipulate data, whether it be on
the client side on the database, and how you can easily just transfer data with you know,
bad security in place. Of course, this is the these attacks will be a very uncommon
now. But again, this was focused on more on an explanation point of view. We're
going to be looking at cross site request forgery, or CSRF. Now, this is an extremely important topic
and a big one that I cover it correctly. So for the purpose of this video, I've set up a very
unique environment that in at least in my opinion, will demonstrate how to utilize or how to perform
this attack. Alright, now I'm just going to give you a brief overview of the environment that
I have no, of course, you can see I have a few files open here. Don't worry about them right now,
just just remember that we'll be using them later on. And I'll be using them really, really well to
explain what's going on here. So you can see as my target or as my vulnerable system I'm going to be
using on my vulnerable web application, I should say, I'm going to be using the OWASP juice shop
now. Not actually no one actually recommended this to me. But I remember that I performed this during
a CTF challenge that I went to earlier, I think late last year. I'm not too sure exactly when
but the whole process was involved in exploiting this web application. Alright, and in my opinion,
this really outlined or really showed of how to perform all of these various web application
attacks. In this case, we're going to be focusing on cross site request forgery. Alright,
so I have the juice shop running it's, it's based on a node.js. And it's running on my local host.
Let me just show you that right now. There we are. So I haven't logged in or done anything
yet. And that's because I'm going to do that with you. So I've set it up, it's running on my local
host. Let's get started with this really, really simple but sometimes complicated topic. Alright,
so cross site request forgery CSRF. Now from the name, you can already tell that it's split
into two into two sections, you have your cross site, and your request forgery. So from that,
we can get a basic example of what's going on here. We have cross site scripting, and we are
going to be forging requests or we are going to be manipulating requests. Hmm, interesting. So we are
we are kind of understanding what's going on here. Now the technical explanation for what CSRF is,
is it is an attack that forces an end user to executed unwanted actions on a web application
in which they're currently authenticated. Alright, so let me put that really, really simply, right,
it's an attack that will force an end user to execute unwanted actions on the web, on a web
application, these actions can be anything, but in this case, we're going to be looking at changing
the password. And they have to be currently authenticated to that web application, which means
they have to be logged in to that web application for this to work. Because if they're logged out,
then you get the idea. It really doesn't help or it doesn't work. Alright, so we use cross site
scripting, in this case to perform the request forgery, and to get either desired or undesired
results. In our case, we're going to be looking at how to to change the password of any user
that's logged in to the to this web application. And how will we How will we be doing that? Well,
we are going to be using CSRF. But the first thing you need to understand is how an HTML form
works. Alright, and this is very important because first of all, a client will request a page from a
server. Alright, the server will then respond and give the the client the HTML form. The client will
then send back the form with the data back to the server server will then authenticate and authorize
the user and then will will perform the requested action. And based on the request and the response,
we are able to forge or to change the request and get a desired response if you're looking at
it from an attackers perspective. Alright, so, the the way CRS CS CSRF works sorry about that
is the attacker will manipulate the victim into submitting the attackers form data to the victims
web server, essentially, essentially performing these these requests in the in our case, as I've
mentioned, it will allow us to change the password of any user on this web application, in this case,
the OWASP juice shop web application. Alright, so now you might be asking, Well, if I'm a bug
bounty hunter, I'm practicing to become a bug bounty hunter. How do I go about finding this
vulnerability? Well, that's a very good question. And that is the question you should be asking
yourself when performing any penetration test. Now, coming back to my environment, I'm running
burp suite, the Community Edition, you you will just need the Community Edition for this one,
we're not performing any advanced techniques here, because we're essentially just changing,
we're just going to be changing the request to get our desired responses. But once we move on to the
advanced stuff, I'll then be using OS zap for our attacks. Alright, so keeping things really,
really simple, we, the way to look for these vulnerabilities is to target the login pages,
which we have right here, we then need to, we can then create the account and log in. And
then finally, we will be creating our own our own script to perform the cross site scripting.
And that will allow us to submit the data or if we send the URL to another user of this
web application who is currently authenticated, it will allow the it will allow us to make them
change their password, and then we can log into their account. Alright, so this vulnerability
is very common on sites with accounts, you know, sites that have emails of passwords. And as you
probably would have guessed, there are a lot of sites that utilize this functionality. But
remember, most of the sites out there will be protected from this vulnerability. So it's up
to you to find these vulnerabilities. Alright, so as I've mentioned, we will be using OWASP juice
shop as our target. And the reason is, is because it will explain what I want to explain really,
really well. Alright, and we'll be using the burp suite Community Edition. Now, as you can see,
I'm currently running the burp proxy, I'm not intercepting any traffic, if I open up burp suite,
I'm not intercepting any traffic. If I go to the proxy, and intercept, I'm not intercepting
anything. So it's currently just I'm just going through the burp proxy and all the traffic and
data is being logged through the proxy. So when it comes down to this little data that I've
saved here, I've already created an account. The reason I've done that is to save time,
because I don't want to explain everything about it. So I've created, I've created a user with the
email of test@test.com and a password of password. So really simple. Again, there's nothing really
complicated here. And if you want if you're wondering what exactly does this mean? Well,
this is a security question with the answer. So the question was, what's my favorite pet,
and I wrote in dog. So hopefully, that doesn't scare you into thinking that I've gone completely
crazy. And then in here we have the scripts that we'll be using, or will be utilizing to perform
the CSRF are on the site, I'll get to this in a second. We don't need that right now. So if
I want to log in, I know that the email is test@test.com. And the password is password.
Alright, so let me do that right now we need to authenticate. So let me log in, like so. And
I'm going to hit test@test.com. Alright, and I'm going to write the password, which is password,
and I'm going to log in. Alright, and I'm don't want to save the password. And there you also
have logged in now. Now as I said, this is very this vulnerability works really, really well when
you're talking about changing passwords, because as you can probably guess, an attacker would would
be looking to exploit this functionality because imagine, if we were able to send a request a get
request to our target with the URL encoded URL. Of course, we can also use link shorteners,
if we wanted to, to do that. And essentially, if they authenticated, it will allow us to make
them change their password simply by clicking on the link, changing their password to whatever
we specify. Alright, so how do we do this? Well, the first thing we need to do is we need to look
at how we get requests are being sent. And we can do that using burp. So we're just going to change
our password. So current password is password. And what I'm going to do is I'm going to change
my password into password. Oops, sorry, pass word 123. And I'm going to repeat it so fast word 123.
And I'm going to hit Alright, so the password was successfully changed. Okay, now let's look at how
this was processed in burp, or how the request was sent in burp. So I'm going to go into burp proxy
and HTTP history. And I'm going to go all the way to the bottom. And as you can see, we have the get
request right over here. Okay, so the get request is very interesting. You can see we have the get
request, and it's targeting the the following URL. And these are the parameters. So change password,
the current password is password, new password 123. And we've repeated it. Alright. So now let
us perform the forgery here. So I'm going to send this in to the repeater. Alright,
so I'm going to click on repeater. And in here, we can manipulate the request and see what responses
we get. All right, in case you, you did not know about that. But again, let's start off really,
really simply. So we are going to be working with the raw request. We don't want to work
with individual parameters, although you could change it, but we are going to be manipulating
the request entirely so that it performs what we want to do. Alright, so what we can do first is
we can test so let's change what if we were to change the current password to something like,
let's see test, let's change it to test and then we hit go, you can see that the response
we get is a is a 401 error, which means we are an authorized to make that and it will give you the
message right here. The current password is not correct. All right, that's good. That is good from
a web application perspective, which means that this web application is performing validation.
And it's not going to allow us to know to just go in and start manipulating any requests and making
changes. So from a security perspective, the web application is doing really, really well. Alright,
what if I was to change the new password? Let me change this back to password to the current
password, which is what we said and change the new password to password pass 123. All right,
and I hit go. Again, we get another error. Again, the 401 unauthorized error telling us that the new
and repeated password do not match. So yes, the current password is correct. And the only thing
that we're getting an error is the new password and the repeated password are not correct. So
interesting. What if we want to change the password into password 123. And we can repeat that
again. So we want to confirm this. So password 123 actually hold on. So I'm going to say password
123. And now let's see what this tells us. This should verify it. But let's see if this works.
So you can see yes, that does work. And we know that this works, because that's what we did that
was the original request. But what if we do not know the current password of the user? Remember,
we're going to be targeting other users of this web application. So what if we get rid of and this
is very, very, this is the way penetration testers go about it. What if we get rid of stuff? So what
if we get rid of the current password? Alright, and now essentially, they get his targeting Change
Password with the question mark here, essentially requesting and we're only entering the fields or
parameters new. And repeat what if we do that and we change them to password 123 I mean,
pass 123 and pass 123. Let go. You can see yes, it does work, we get the 200, the 200 response,
which means everything was processed correctly. And we were able to get a password that looks
to be hash, that looks to be hashed. And we got the email that we used. So yes, we do know that
it is working. Alright, so we know that we know that this worked. But we need to confirm that
this has worked. So we can do this by going back into our web application. And we can log out and
we can try and log in again. So log in with our new password. So we're gonna say test@test.com,
and our new password was passed 123. Remember, we changed it earlier. But again, I was demonstrating
that we if we are to send this to our target, we need to specify to make sure that it will work
without any pre required information like their current password. So I've manipulated the request
there. So let's hit log in. And voila, you can see it does work. Excellent. All right. So this is a
fantastic example of so also CSRF can be utilized or how it can be how you can find vulnerabilities
for it. Alright, so this can allow us to change or update anyone's password. anyone's accounts
password that are currently logged into this web application. Alright, so now what we what we need
to do well, we can we can log in. As we've already seen, we can log in and once you've logged in,
we can we can test to see if cross site scripting does work. And then of course utilizing it
throughout the web application is very important. So We can run a simple cross site script attack to
see if it will work on the search bar right here. So I'm going to type in script. And a simple one.
So alert, just to test whether it works. And in the alert, we can say, Hello, just something
stupid hello world, you know, that's an I can't even type man Come on world. And we've typed in
the alert. And we can finally close the script here. Script like so. And let's hit search.
And voila, we can see that indeed, cross site scripting work works, which means we can insert,
we can insert our GET request inside a script and use a cross site scripting to perform the CSRF.
And now you can see them conjoining together, cross site scripting with request forgery. Okay,
so we now need to create our custom script that will allow us to utilize the attack.
And we will be using XML and HTTP. Now, you might have seen this script right over here,
let me just minimize this and open up leafpad, you might have seen this script that I created. Now
you can find many of these CSRS scripts are online that utilize different languages. In my case,
I find the one that works the best is the is the one that works with x XML and HTTP
and contains the get request in here. Okay, now, you can see that the get request requires the URL
in which we submit the the parameters without the current password. So we need to go back into burp.
And it needs to go back into proxy HTTP. Sorry about that HTTP, we look to change the password.
So if we go back into, sorry, the repeater. And if we look at this now, we can see that the URL
is right over here. So that's the get request. So if we copy this localhost, obviously, and we are
not using any current password field, so if we can do that, really, really simply, you can see
how this can be utilized really, really well. So what we need to do now is understand how the URL
will be format. And of course, the web application is going to encode it, and I'll get to that in a
second. So we need to copy this URL right here. So I'm just going to copy the URL. And we can
edit our our script. So HTTPS, and we paste it in inside the URL, you can copy this script if you
want to. Let's take a look at whether this script is formatted correctly. So get HTTP new, that's
not the way we want it. Let me get rid of the pre pre determined HTTP there. So HTTP localhost,
it's hosted on my localhost with the Port 3000 node, an OJS standard. And the we want to change
the password, the new password is past 123 and repeat his past 123, you can change that to
whatever you want, if you want to, you know, play around with the script. But in my case, I don't
want to do any of that. So this is the script. So what we can do is we can copy this now. And we can
run this in the search bar. And that should, in theory, and in practice, give us our first CSRF
attack on the site. So I'm going to paste this in here. And let's see whether it does this. So I'm
gonna hit search. And you can see you successfully solved the challenge error handling provoked an
error that is not very gracefully handle. Again, this is a fantastic web application vulnerable web
application that is awesome for practicing your your web application penetration testing skills.
Now, I talked about the URL that you should send to your target. And that is the URL that will
essentially make them change their password or without them knowing, given that they are logged
in to the web application or they have an account, it will not work if they have not logged in.
Alright, so that's very important to understand. And many people just you know, forget about this.
Now. Again, if you could have done this, you I can log out again, and I can log in try and log
in now. And I can type in for example test I just want to show you something very interesting here
test. And I can change the password, we already changed it to password 123. Now before I do that,
I can just inspect the element here. And I'm going to hit login. And I just wanted you to
check something out. All right now, let me just expand this a little bit here. If we were to
look at the network, this will essentially shows all the GET requests. So if I was to hit login,
you can see that if we are to look at the get request here the login GET request,
you can go ahead and look at at the exact format in which it was sent. You can look at the cookie
the it should give you the the authentication token not to show it should give you the authentic
the authentication token. But that's something for another day. Don't want to complicate you guys,
you can look at the cookie if you want to. And you have all the responses right here. So there we
are. There's the authentication token and you can see something very interesting in regards to the
token. Alright, so let me show you this right now. Alright, so as I was saying, you can see. Alright,
so as I was saying, you can see that if we look at the parameters, the password will be displayed
there, and it will be updated to the one that we selected or specified in the script. Alright,
so remember, if you want to customize the cross site scripting attack, you can do it through your
script. And where is lifted here. So there we are. So you can change the password. The as you see,
we just got rid of the current password parameter, which is a vulnerability on the site, but you can
change the password to whatever you want. And now you might be asking, as I've mentioned, what
link do you send to the target and that is very, very simple. If I was to run the script again,
and I change the password to maybe something else like password 124, or 345, sorry, 345. Let me just
add that to the password. And I run the script on an authenticated user, which is me. So let me copy
that. And it should change my account password. And you can see once I log in, log out and try
logging in, it will have changed it successfully. So let me just run it in here. So I'm going to
paste the new one in here. And I'm going to search and there we are. So now it's changed my password.
And if I log out, and I try and log in with with the old password, which is password 123, you can
see whoops, sorry, I think I typed that in wrongly 123 like so, fight login, there we are, you can
see that we entered the new password, and it did work fantastic. So we were successfully able to
execute the script. And again, when if I just run the script, again, this is the URL that you will
send to your target. Alright, so if I just copy it, and I inspect it in my leafpad here, I really
love leafpad. I don't know that you guys love it, too. If I just inspect it, you can see that this
indeed is a URL. And if the web application was being hosted on a server, outside my local area
network, it would give you the website name, the port, if it is port specific, and the URL here,
which as you can see is encoded. So what I would recommend is that you copy this link here,
and you use a link shortener like bit fly or any of the other Google shorteners, and you send that
to your target. And once they click on the link, and if they already logged in to this specific
web application, it will update their password. And you can essentially, you have the password
now because you've updated it. And you're all you need is the email, which I'm pretty sure you must
be knowing if you're performing this attack. Or you could just be gathering passwords of users,
all of which you can, you can send this link to and are authenticated with the web application.
We're going to be taking a look at session management. And in this video, particularly,
we'll be looking at cookie collection. Alright, so as you know, you probably would have known what a
cookie is. Now there are three types of cookies that we really need to be focusing on in this
section. And we will be focusing on in general. The first one is the session cookies, which I'll
discuss in a while we then have the permanent cookies and the third party cookies. So third
party cookies are really all to do with third party API's that may be used. So for example,
if you're on a website that utilizes flashplayer, you may find some cookies, that that are in relate
that are related to the Flash Player. So it's very important that you understand how to collect these
cookies. And as well, we'll be looking at reverse engineering them, but not really tampering with
them. Because I first want to explain to you guys how everything is done. And then we can move on
into into finally tampering with them and seeing if we can change them to give us access to give us
different type of of access. And where this comes into play is when you're talking about session
cookies. And in this session cookies, we have the the auth, the authentication token, and the D and
the unauthenticated token. So all to do with your access on a web application or on a website. Okay,
so essentially, all the cookies that you can probably ever get when you visit or you get
when you visit a website are they are generated when you visit the website. And furthermore,
the cookies change when you authenticate with the website and you or you log out right so when
you log in, you get a different set of cookies. And when you log out, you get a different set of
cookies. This is where the whole idea of session management comes into play and how cookies are
utilized for this system. So I'm currently running OSU shop. So I showed you guys how to set that up.
Let me know if you found it helpful. So I have it set up and open as it opened up in my browser.
Now what I'm going to be covering is how to collect these cookies and understanding the
difference between an unauthenticated cookie and the authenticated cookie. So Usually,
what I have, or what I use to my advantage is if you're using Google Chrome or Firefox,
you you can get a cookie collection or a cookie editor add on that allows you to edit the cookies.
But as I said, we're not going to be looking at editing them right now, because we don't know
what to change in them, this video is going to be focused on collecting them and then analyzing
them to see what information they have within them. All right, so I've currently I reset this,
the OWASP juice shop. And the reason I did that is just to start off fresh. And I said, we're
going to be using this for performing all of the examples that we'll be showing you so that we can
learn all the concepts. So I'm just gonna, before we log in, I just want to show you the first set
of cookies that we'll get once we were when we visited the site. Don't worry about the other
links, we'll get to them in a second. Alright, so I'm using the cookie editor right here, you can
find this same one for Firefox, that's what I'm using. They are also other ones for Google Chrome,
if you want to do that. And in addition, we're not going to be using any proxy, like burp suite
or the OWASP zap right now, because we're just focused on using the browser tools. And of course,
these add ons here. So what I can do now is if I just go right click, and I hit Inspect Element, we
have the, the developer tools right here. And if we are to go into Once you've installed the cookie
editor, you can directly go into storage. And in storage, you will, you will begin you will get the
cookies here and other values right here. But if you it'll be better for you to understand what's
going on if you go into the cookie editor. Now in the cookie editor, you can see that we have
two cookies that we've gathered here, and we have the cookie consent status. And the the i o which
I'm not sure really what it does input output, output, I'm probably guessing. So when it comes
down to the QB, consent status, we probably get an idea of what of what this is. What this is asking
us. So when I when I opened up the website, it gave me a prompt asking me like all websites will
ask you in 2018 to do is to accept their privacy policy, in their privacy policies in regards to
their use of personal data and cookies. And the reason is, is because cookies can can log or have
a lot of information about you. They contain a lot of information about what your what you've
been doing. So this is why I've created this right now before we move along, it's very important to
understand their role in session management. Okay, so we need to look at the authentic authentication
tokens because that's where most of the magic happens, as you would expect. So let me just close
this up. And let me just log in. So let me just use the password there, the email that I used,
and the password, like so. And let me just log in. I don't want to save the password. So I've logged
in now. And if I inspect the element, again, you can see in the cookie editor, let that load,
it usually takes a while to load. There we are, we have the token. Now the token, this token is
an authentication token. Alright, so when it comes down, when it comes down to reverse engineering a
token, for example, let's use this as our example. We essentially testing it for vulnerabilities
similar to a penetration test. Now you might be a little bit confused. You might be asking, Well,
what what what do you mean by this? How can we perform a penetration test on this token? Well,
this token is encoded. Alright. So this is if we just copy this. I don't know whether you know
about this, but this is a JSON web token. Alright. So it is it is a JSON web token. And you can use
the JSON Web Token decoder, I'll be posting this link in the description. This is the one that
I prefer to use. If I am to paste this in here. And you can see once I've pasted it in here, it's
going to give me all information. And I'm going to help you understand what we've just done. So
essentially, what we have done is we have reverse engineered what this web token is all about. So
now we need to look at what what it contains and what type of authorities or privileges it's giving
to us. Because remember, this is an authentication token. And it is unique to us because this will,
this will determine whether or not we're logged into a site or we're logged out and what access
we have on the website. I'm pretty sure you already know that. All right. So when it comes to
the header, now, this is very important. I've seen many web people claiming to be bug bounty hunters
and they don't understand how the the web token is even structured. What is the header the header is
separated from the payload. This is the header right here, up until the first full stop that
is the header it's very important to understand that because they are separated from each other.
In fact, the JSON web token is sorted into three parts right here you have the you have the header,
you then have the payload until here. And then finally you have the signature which is right,
right at the bottom here which is also separated from the rest. Okay, so when it comes down to the
header, alright, the header is going to give you the of the of the token. In this case,
we know it's a JSON web token, we then have the algorithm, which is the hashing algorithm used,
which is the RS 256. And then the payload now in the payload, this is where things get
really interesting as you would have expected, you have the status, the status code here, the data,
if any data was passed the ID, we can always use the ID. Two, we can always edit the ID to see what
else it can give us in terms of authentication, because different types of identification or
identification tokens give us different types of access. So, as essentially this is what I was
talking about, this is where you will scrutinize the the the authentication token, and try and and
tamper with it to to see what different results you can you can get. So remember, we can edit this
token, right, and we can edit anything about it. And then we can finally copy it. And we can use
that in the OSB shop and paste it right here and re authenticate with that new token and see what
results we can get. Now, of course, we're not going to do that right now, because I wanted to
introduce you as to what information you're going to find and what exactly is going on here. Okay,
so one step at a time. So you can see that something interesting pops up here, something
extremely interesting, we have the email which for some reason, in this token, we can see that
it's not very well designed because the email is in plain text, which means which means if In any
case, or in any scenario, someone is able to get this token in which I authenticated within a site,
they will have access to my email and my password. But you must be saying, Well, I didn't see you
type out all of these random passwords here. Well, I can easily guess that this is an MD five hashed
password, which means I can depending on the on the strength of the password, I can decrypt
online in a second using any of the decryption tools. So if I was to just copy this right now,
and I wanted to know the password, let's say this wasn't even mine, this authentication token wasn't
even mine, and I found the the email and password, all I needed to do was unmatched the password,
I can go to Mt five online.org, which is what I use a lot. And I paste that hash right in here.
And I hit decrypt. And you can see, well, first of all, it's gonna prompt me to enter capture
your storefront. This is this is getting really annoying. Now, for some reason, it always does
that, as you can see, it's gonna, it's gonna find the action. Of course, this is this is dependent
on the difficulty of the hash and whether or not it can find it online. Okay, so you can see that
it will display the hash and the password in plain text, which in this case was passed 123. Now,
of course, you can experiment with this. And you can also experiment if, for example,
the authentication token that you found was using a different encryption, or a hashing algorithm for
the password, the first thing you need to do is identify what it's using, and then you go about
decrypting it. Now, I'm not going to be talking about the other parts here, because that's a bit
that's a bit advanced. As you can see, by default, the signature, the token signature failed,
which means we can tamper with this token, and we can make changes to it. And we can authenticate
with it because it said, The OWASP juice shop is is designed to be vulnerable. And this is where
you perform all of these tests. Okay, so when it comes down to the payload, the most important
things are to look for the status, the ID and obviously, if you can get any other information
in the data section, or in terms of the email and the password, that's also very important. Now,
of course, it's not very easy to get a hold of someone's of someone's token, but you can do
it but and then you are performing the penetration test on the token, because if someone was to write
in the comment section of this video, what it was to grab the the authentication token that belongs
to Facebook lets you have access to someone's computer for a few seconds. And as to get the
authentication token, what would I be able to do? Well, first of all, you have to test the security
of the token. And I can guarantee you that their tokens are going to be very well secured and
performing the penetration or the penetration test on them will be a different ballgame. So we'll be
looking at changing them or or tempering them to give us different types of access. We're going to
be talking about HTTP attribute attributes and cookie security. I am currently running OSU shop
and what I did is I started a fresh new instance. So I unzipped a new OSU shop. That's because I
wanted to start afresh Now, of course, in the previous video, we looked at cookie analysis
and tokens. But now we're going to look at how at the security aspect of how these cookies are
secured and how you know how cookies are stolen and how these can be exploited with with with
other exploits or functionality like cross site scripting. Now you will get to what I'm saying
in a few seconds. So I have was used Stop running. And I've created the same user and password as I
did last time. So it's a test@test.com, that being the email and the password is password 123. Just
so you know. And I'll do that right now I'm just going to log in, as you can see, test@test.com
and the password is password 123. So let me just log in. And there you are. So I've logged in and
haven't solved any challenges. So when we talk about cookie security, what do I mean? Well,
this can be done or can be inspected really easily. Now, of course, for this, you're not going
to need any of the browser extensions or add ons, because we'll just simply just be inspecting the
element here. So if we open inspect element and go into storage, and we go into cookies, and select
the site, which is on localhost, you can see that if I was to click on, for example, the token,
and we just look at the data, you know, that we can see within the token, if we go to the HTTP
only section here, you can see that that is set to false. Now, what does that mean? Well, that means
that we can potentially exploit this cookie and it storage location in the sense that it is it is, it
is not secured. Now, I'll get to why and how this is happening in the in a few seconds. Alright,
so if the value is set to false, it means that the cookie can be accessed and written to now how can
one use this, you know, for potential attacks, or Cookie, cookie stealing, as we know it. Now,
if you are an advanced web application penetration test, and you know about cross site scripting, you
know, that usually attackers will use cross site scripting, to steal cookies, by sending you links,
that then, you know, by sending you links to pages on the site, that you're already authenticated to,
that have the the the malicious JavaScript code that will then send your cookie,
your authentication cookie with your token, etc, etc, to their attack server. And from that,
they can then use that to authenticate into your account, it's not common, because mostly, the,
the cookies are usually secured. Now, you will run into sites that have this and this is a very,
very big vulnerability in terms of severity. So if you're a bug bounty hunter, this is in the medium
to low category, so not really a big exploit, but still a very, very big problem that many, many,
you know, usually, I would like to say rookie developers Miss, especially when dealing with
huge frameworks like node etc. I'm not going to get too deep into that. So you can see that the
HTTP only is set to false. Now, what does this mean? This means that we can use utilize a lot of
functionality to exploit or to display the broken or even more to send this my cookie or you know,
my token, whatever you want to call it to a server or to save it, alright, to grab it to steal it,
you know, simply put, so how can we exploit this? Well, we can use cross site scripting,
and this is probably the most used method for this. And to do this, we can simply,
we can use any of the, we can use the search, or we can use the contact. But I like using search
because usually it is unfiltered. Now, when I say this, I'm you know, many of you will say,
Well, most of the big sites, well, I'm not talking about the big sites, the big sites, obviously have
to take this into consideration. I'm talking about sites that are developed by small teams,
they usually don't take this into consideration. So if I was to just type in a simple cross site
scripting script that will essentially display my cookie right now as I'm authenticated. So to
do that, I'll just type in script. And for this, we're using an alert here to display
to us so alert, and we're gonna say document, whoops, stop, sorry, document, dot cookie. And,
and then we're gonna just close the script like so. So this will display our cookie to us. Not
really helpful. But you can imagine if we were to have this permanently posted, for example, as
a post here, and then whenever we send that link to someone, and they click on it, we can customize
this JavaScript code to send their cookie to our web server. And once we get their cookie,
you basically know what's gonna happen there. So if I hit Enter to search, you can see that it's
going to display our cookie and our token, and this is extremely dangerous. You might not get
the context, but I'll explain it in a second. So essentially, this information can be passed and
sent anywhere across the world, provided that the that your target clicks, clicks on a link in which
this, this script is executed. Now, the question that you might be asking yourself as well, where
else can we post this in in sort of a malicious way and I know that I sound malicious right now,
but I'll also get into how to mitigate this. And again, mitigating It is really simple. Just set
your HTTP status or your HTTP attribute to true or set it to on essentially securing your cookie now
You can see that once we have this, you saw in the previous video, what we could do with such
information, and what info it contains in regards to the user. And how we can, we can, you know,
crack the password. But for now let's focus on how this can be utilized to steal the cookie or how
attackers do it. So you can also get insight if you're a white hat. So usually I can post this in
here, I can put, you know, I can type the script in here. But this is not, it's probably not the
best way of doing it. Because you essentially have to convince the user to go into the search
bar and type this in. Not really the best of ways about going about going about this. So usually,
we look for a page that allows us to, you know, to post our own stuff, or to save this to a database
or to save it to the website itself. So we let's try contact us. Alright, so contact us. Yeah,
that looks like a good place to start. So in the comment you it already added our author for so in
the comment, we can enter, we can end our script in Yeah, and this will probably probably be saved.
But we have to test it. Now. Of course, the cookie stealing JavaScript code is not something that I'm
going to be telling you how to do, you can probably perform a lot of Google searches,
it's part of the terms that I have to follow. In regards to YouTube's YouTube's policies
about malicious content, and when what not, so I'm not going to show you the exact code,
but I'll probably have it on my website, if you want to take a look at it and experiment as to how
to send cookies to a another server or server that belongs to you, for example. So to do this, so now
essentially, what I want to do is I want to save this script, into the contacts section, because
I believe this is saved. If I looked, I looked at the structure. And indeed, this is saved. So the
script is quite simple. So we can say, we can give it a title because I know the feedback is
left like that. So we can say script test. And we can close the script here. So scripts, but then we
have to include the the actual JavaScript code. So yeah, so let's include this script within the main
one. So script. And then once we close this one, we can then use the other script. So your script,
whoops script in, you can copy this code if you want. By the way, let me just zoom in,
because a lot of you had actually talked to me about that, that you couldn't actually see the
code. So script. And now we want to bring up the alert. Now, of course, as I said, this is
not really useful, because all you're doing is displaying the cookie to the user themselves,
once they visit this page, so you probably get the idea. So script, alert, and we are
just simply just going to write the document, of course, it's all sending it to a malicious server,
what I would have done is I would have used the document dot cookie, and I would have appended it
to be sent in in the form of probably a PHP file or a PHP GET request to my server, and then my
server would log all of the information being sent back. So that's the concept there behind so we can
then close the script here. And sorry, we have to actually close the script. Oops, sorry, my bad.
And then we close the script there. And finally, we can close the final script ending here. So
script and there we are. And we can leave a rating if we want to. And there is a CAPTCHA here
authentication 10 plus five. You You basically, this is also an exploit here that you can enter.
Because if you look at this very basically, from a simple perspective, the capture here is again,
is another false positive. And again, I know I'm dragging this, I'm dragging it a lot. But But what
I'm trying to explain here is, if you are going to, you're going to be performing a penetration
test on a web site, you need to understand that, from the perspective of false positives, you
should not go after the big exploitations or the big exploits first. Alright, so if I submit this,
as I know the structure of the OSU shop, this will be submitted to one of the pages in which after
I click, or any other user who is authenticated clicks, will will run that script, or this script
and will the cookie will be displayed on the screen. And if you want to manipulate or use
your own script to send the cookie to your server, by all means go and do that. I'm not condoning it.
So that is 75. And I hit submit. And what nots wrong capture 10 plus five, actually, 25. Yes,
brackets of division multiplication addition, you guys must be thinking I suck at math. So that is
25 plus five, plus 10. Sorry, that's 3535. And I submit that whoops, we have to actually type our
code back in Sorry about that, guys. So we can just type in script, and we're simply testing
test. And then after this, we can close the first one. And script here. Whoops, sorry about that my
keyboard is quite a distance from me. Alert. And my spelling mistakes are really annoying script.
And finally, we can use the document. My God, man my typing document dot alert dot cookie, sorry,
we are we have already sent the alert, we will use the doc document, that alert would essentially
display the entire webpage, document dot cookie. And in here, we close the first script. And sorry,
the the initial script. And then we close the last one year. So script. And we close that right
there. And finally, we can give this a rating and resubmit. And that should submit it. I don't know
what the issue is here. And then there we are. Also some Alright, so there we are. Thank you for
your feedback. So you did submitted there. Let me zoom back out. Now, you can see that, where would
you go to launch the script? That's, that that will be the question that you might be asking.
So on this in this structure, you can pretty much experiment with all the other pages. And again,
I do recommend that you use you know directory discovery tools, like there Buster go buster,
whatever is comfortable for you. So with this in mind, if I was to just click on About Us,
you can see that that is where the the the feedback in regards to contact is stored.
So there you are, there's the cookie. And if I was to if I was to have implemented a script
that would send the cookie to my server, once I access to this page as an authenticated user,
it would send my my session ID all of that good stuff to my web server, I now be able to crack the
password and authenticate with your account. As simple as that without ever knowing your password
without ever trying to have guessed it without without ever trying to have exploited your system.
I exploited the web application. And because of the the ability of the developer of the web
application to secure the cookies, I was able to get into your account and god knows what else you
can do in that person's account. And this is you know, this is tribute to my all my Facebook hacker
friends out there who think hacking Facebook is about cracking and brute forcing. There you go,
you know, web applications can can be cracked in or can be exploited in different ways. Now,
of course, as I said, it's going to get really exciting as we move along with Duchamp. And
that's the reason I'm using it because it explains how this can be done on a real website. And yeah,
we're going to be looking at OWASP juice shop. And it seems to replicate what a real web application
would be a fairly poorly designed one. But the thing I like about it is, it has varying levels,
levels of difficulty. And that's really, really awesome. I have it set up on Heroku,
as you can probably see right over here. And that works perfectly fine for me because I you know,
I wanted to set it up really quickly, I want to run it on my local server, you know, using node
or Docker. That's really is, I really didn't have the time to do that. But if you want to you can,
you can use Heroku. And it should be free for you. So yeah, definitely go ahead and give it
a try. And you should have a an instance set up for yourself. So you can go ahead and do it. And
it's giving us a prompt here telling us that this website uses fruit cookies to ensure you
get the juiciest tracking experience. Now, from my experience, I would hit accept the cookies because
essentially, that's what keeps track of your progress. And yeah, that's pretty, that should
be quite good. Now as for my browser, I'm using the latest version of Firefox and I have you know,
plugins or add ons like cookie editor. And that's pretty much what we'll be needing In this video,
I hope and we don't have the the proxies here like sorry, Foxy proxy to allow us to use things like
burp suite or zap whatever you want to use. OK, so let's get started. Now the first challenge,
as I believe is to get the the scoreboard and we should start from there. And to do this,
I think I have done this already. That's really very simple. All we need to do is well first of
all before we actually do that, the interface is quite simple. It is a juice shop as you probably
can see and could have understood and they sold juice. Now the great thing that I like
about OSU shop is that this replicates a real life a web application with you know, security,
misconfigurations, etc, etc. So if I log in, you have your login page right over there, man,
you can create a new account if you want to, you can search where the Contact Us page allows us to,
you know, essentially contact whoever is behind the site. Then we have an About Us page. And
the thing I like about this is, as I said, it replicates what I would call a real web
application. Now when you talk about, about the scoreboard, I think that can be accessed really
quickly by going into scoreboard like so. So, you know, we can just hit scoreboard. And if I enter,
that should give us the scoreboard. Alright, so it gives us the notification once you've
completed the challenge, and the reason it does this is to notify you of your progress. Remember,
this can be considered a capture the flag type of challenge, but I wouldn't call it this I think
this is fantastic for essentially explaining the concept here. Alright, so let me explain how the
scoreboard is essentially works. Alright, so a scoreboard is as follows. Sorry about that,
if you had my phone, it always seems to do that. So we have, we have the challenges
sorted in terms of difficulty. So we have a one star, two star, three star, four star,
five star and six star. And they all have various challenges within them. So for example,
the the difficulty sought in terms of star so you get the idea, one star is quite easy, two stars,
you know, not so easy, we have three stars, things are getting a bit sweaty here, four stars,
now we're talking five stars, I'm banging my head on the wall, and six stars, that's going to take
you probably a few, a few days, or, you know, hours depending on your determination. Alright,
so you can see it also gives you the gives you the challenge names here. So if I click on the
two star challenges, you can go ahead and look at the challenges there. And we brought I think in
the previous videos, we covered a lot of the two star and three some of the four star challenges
that we wanted to go through. So the three star challenges are where things get really awesome,
because it does start logging in with other users. And there's a bit of cross site scripting,
I'm not going to go through all of that, let's start off with what we can do. Alright,
so the first challenge in the first is access the administration section of the store, or right,
so I'm guessing we have to try and log in, I think I've done this, this is the first challenge,
we have to access a confidential document provoked an error. That is not gracefully, very gracefully
handled, not to show that is let us redirect you. I'll try and cover as many as I can. In one video,
we have cross site scripting attack. This was simple. I think we covered this. So yeah, we can
pretty much run that in one of these right over here. So script, and alert, as it already gives
you hints these are very, very easy. So I can just say test. Have I given the OP Sorry, my bad.
So yeah, there we are test. And we close that up. And we also close the script right over here. And
we hit Enter. And there we are. So that is one of the challenges solved, hopefully did pop up there.
So if we go back to the scoreboard, it still tells us for some reason, the web application is
too low, it's not told us that we have performed a reflected cross site scripting, all those I don't
know, right, so reflected. Anyway, we'll get to that when we get to it. So if we inspect the login
page, what we can do is we can create a user. So I'm going to create a user here. And I'll just use
a simple user here called test@test.com. And the password or call that password. And I'm going to
repeat the password here. And I'll just call the password password. And I'm just going to use name
of your favorite pet. And I'm just going to say dog right over here. I'm going to hit register.
And we're going to save that. Alright, so I can log in now. Did I log in with the correct test?
Yeah, there we are. And we're going to log in, and we are logged in. Alright, so let me just
zoom out. So the interface does not really crashed on us. Let me just get rid of that. All right,
so it's sorted out really well. We have the language selector here your basket, which
essentially allows you to select your to view the items in your basket, you then have your coupon
if you want, if you want to use a coupon and you have your checkout, which essentially I believe
takes you to the the OWASP juice shop, donate page if I'm not wrong. Let's just see if that
is correct. Yeah, yeah. So if you want to support the project, I would, you know, you can donate to
them. It's a really great project. I really do recommend that if you can you do so. So you can
change your password, which is awesome. I think we also took a look at this and how to change
it using using the GET requests. Contact us where you can necessarily write in, you can contact the
person via the site or the administrator as I would believe. You can comment, recycle recycle
what this requester recycling box so you can type in liters here that has a selector. Alright, okay,
that's not too bad. We have a complaints board. And the scoreboard itself here, which for some
reason, keeps doesn't really load. So let's try and work on the first section. As I mentioned,
I'll try and cover as much as I can here. And you have the About Us here that has some sort of
Let's see some sort of checkout or boring terms of views. Let me just check the scoreboard what
exactly are we supposed to do? Because access the administration section? What's in the two star
here? login with the administrator. All right, so we're trying to access the administration section.
So let's try and access that right over here. So I'm just gonna type in admin administration,
like so I'm gonna hit Enter. And yeah, that was pretty easy. And we get the email right over here,
admin and do shop. That's the admin email. And we have all the emails right over here. So we have
you met juice, juice shop, Bender, and some other uses. And we have also, yeah, alright, so we got
the registered users customer feedback, and the recycling requests that have been posted so far.
Which means you're starting from the basics. So I think we can try and log in with admin,
but we don't know the password. So yeah, so I'm just going to log out. And let's see if we can log
in with the password here. admin, I do shop, and I probably I'm probably guessing we have to use
SQL injection. And in this case, I think I know what to do, because I have done this before. But
it has been changed quite a bit since the last time because I think in the previous versions,
it was with admin only, there was no domain oza username, I'm not too sure. Anyway,
let's try and see if we can throw some errors here. So if I log in, alright,
so that means you have to provide a password. So let me just try and use the single quotation. And
let's see if that Yeah, it does throw an error. And there Yeah, we completed the other challenge,
which you successfully solved the challenge error handling provacan errors here. So essentially,
performing error enumeration, if that's something you've never heard of, it's essentially where you
just try and see all the CE o 's fuzzing really just throwing, you know, information at the
system, seeing how it responds. And we get here the query. So we are performing SQL injection,
because as you can see, tells us here we have the the query right over here, which is telling
us select and what this is saying is select all entries from the user table where emails
are equal to and we specify the single quotation. And the password is what is this? This looks like
a hash? What hash is this? Let me just check. I'm think it might be MD. Five, I'm not too sure. Let
me just check this hash identifier. And we just paste that in there. Sorry about that. Let me
just paste that in there. Yeah, this is an MD five hash. So that probably let's just see if
we can decrypt that or decode that. So I'm just gonna say MD five decrypter, or something like
that. Let's just see if we can do this online really quickly. Come on, come on. I want to see
what error because that's, that's a password. Let's decrypt that. And we'll for some reason,
it's taking too much time here. So yeah, yeah, it's essentially hashing the password. Alright,
interesting stuff there. We actually now know that the password is being hashed, obviously, you know,
with the Mt. Five, hashing algorithm or protocol, whatever you wanna call it. So original. And yeah,
that is the query statement there. So we can try some basic SQL injection. And some of the basic
ones to log into admin or to essentially log into the administration, the admin panel is,
now the thing that's weird is are we going to use the password do we're trying to get authentication
so that means let me disclose that. That means if we just throw the error one more time,
or get the when you were able to get the query here. So we are saying select actually start from
there. Select from users, so select all queries, all entries from the user table, from where email
use the table. So there's users Alright, so the user, the user table as email and password, okay,
I follow now. So that means we can try we can try, we can try and use the or statement here.
And probably we can use the not statement if we are going to Yeah, that will make a lot of sense,
but we only using email so we'll keep the single quotation. So what that means is,
is if you know about SQL injection, hopefully I can explain what's going on here. So we know that
the password is being hashed, we're saying select from the table where email and password. So that's
the statement. So select from the table for sort of select from the users table where the email
and password is going to be equal to is going to be equal to what we have entered. But remember,
the the password has to be has to stay as the single quotation. So that means your we are
going to be using the or so this is basic use, you guys should be knowing this, but if you want
me to cover it, let me know so or equals or so or one equals one. And the other ways of doing this,
I think I'll post a cheat sheet in the description section, you can check it out for yourself just
to get up to scratch with what's happening. So what we're saying is we're using the or the or
the syntax of or is very simple. It's where we have the what's happening here is we're seeing,
we're seeing Okay, so if you know the syntax for how a query is made in SQL, it's really
very simple. So we're saying select from, from the table, remember, this is specifying a table,
not a column. So it says select from the users table from select from the users table,
email password, so comparing and then we say all the new specify the condition with a value,
we can enter our into fields. So we can say the value of the email can always be changed. And we
obviously know that that is the first account that was created. And the password is going to
remain the same. So we hit login. And yeah, we get still keep on getting an error here. Now,
that is weird. No, because if I specify there is no comment here, or one equals one, yes. So it is
working. So you can see. So select from users, where one equals one and password. Yeah, so we
want to nullify and password we don't want and there. So for that we use the user comment here.
And there we are. Excellent. So we're able to log in to the administrators use account. Alright,
so let me explain what happened there. So as I said, the the syntax of the query was as follows
we're selecting from the users table, we're selecting the email and password and comparing
them to each other. So they have to match show up, you're performing a query, a simple query,
and what we said is, or that's a conditional statement. So we're saying or that we specify
the condition where the first value is going to be equal to the the, the first one is going to
be equal to one, and we nullify the, the password where the password was we're essentially removing
authentication. And we are what because we're including the comment syntax for SQL. Alright,
so that was pretty simple. But now, the thing that's bothering me is we don't have the
password. So let me just check the scoreboard. And let's see what progress we've made so far.
So have access administration section that's not in here that is in here. So log in with the
administrators use account. Marino the password. So I think that's how we're going to be logging
in. We know the email, because if I just go back into administration here, administration, I hope
the video is not getting too long. So we have the admin. We have the admin email here. Um, oh, yes,
yes, yes, yes, we have the token. So if we inspect the element, and we go into the cookie editor,
for example, we can use that or you can just use storage. But I should have done it, you know,
from the cookie editor from the beginning. So we have the the token here. And I talked about this
in my other video actually went through this with the token. So. So we're gonna say token,
I think the site was it's a JSON tokens, a token, decode, and should be the first site here, the
JSON web token. So jw t.io. That's an excellent site. And we talked about this. So if you want to
watch that video, I'll post it in the description. So you can check it out. And the email is admin.
So that's the authentication token, and that gives us all the information we need. All right,
so we have the password here. But again, what is this hashed into? That looks like MD five again,
but let me just confirm, and let's see what that gives us. So the password is hashed,
as we know with MB five, so let's just confirm hash identifier, because there we are. Yeah,
it is MD five. So let's just decrypt that one more time. So I'm just gonna paste in that hash there.
I'm just going to decrypt let's give that a few seconds. Oh, my God, man, all the traffic lights.
And let's hit verify. And yeah, there we are. The password is I mean 123 Yeah, that's that's pretty
basic, but again, replicating common practice that you would find. So what was the email? Oh,
boy, what was the email? Let me just log back out. Correct. All right. So let me just use the
statements. Oh, yeah. So we're logging in. So all one equals one, because we're all the waters the
I think we can access the the middle from the administration. Sorry about that, guys. I know,
I'm getting really mixed up. Well, we're not logged in yet. So anyway, let me just
log in. And we can do the administration here. stration. And the admin I do shop at juice shop,
a juice.up. Yeah, that's there to confuse people. So you can guess it? And we're
logging in with that. And the password is admin 123. We're going to log in, and yeah,
fantastic. So you solve the challenge password strength. So that was the problem there. That's
the vulnerability that they're trying to say exists. So you know, again, password strength is
something that people don't take into account, login within message user credentials, without
previously changing them or applying SQL. Could you have done this with SQL injection? Probably,
I'll have to cover SQL injection, because we know SQL injection is one of those things that's really
dependent on the query. So let me just go back to the scoreboard here. I don't understand what else
is left. There's still a lot of stuff that have to cover. I talked about cross site scripting,
but I think I'll cover that in the next video. We'll explain it again. What is the what is the
the confidential document error handling? Or we don't have anything much they're actually someone
else's basket? I did that. What else should I want to cover here? Let's look at these ones right over
here. So yeah, so the authentication area here is where I want to look at. I think that's where
I'm going to end this video. I know, I haven't covered any advanced stuff. But hopefully that's
like an introduction. So where we, where we have been able to log into the administration in the
administrators account, we are able to get the scoreboard the administration panel, what else
were we able to do? We were able to provoke an error, not saying no nothing really complex
there. And we were able to log in with the admin tree at the administrators group user credentials.
Now we looks like we can actually get access to Max's search original users credential so again,
another user that we can try and get access into. Yeah, that's gonna be it for this video. Guys. If
you found value in this video, please leave a like down below. If you have any questions
or suggestions, let me know in the comment section on my social networks or on my website,
and I'll be sure to leave your reply and I'll be seeing you in the next video. Peace, guys.