Transcript for:
Web Application Penetration Testing Overview

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 [email protected] 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  [email protected]. 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 [email protected]. 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 [email protected],   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 [email protected], 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, [email protected]   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 [email protected]. 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.