Web Application Vulnerabilities

0:05Most of us use web applications every day.

0:09I'm talking about, like, online banking.

0:12And who does their grocery shopping online?

0:14Who uses Amazon?

0:16I mean, webmail, all these things

0:18are web-based applications.

0:21And many of them have vulnerabilities in them

0:23that can be exploited and attacked

0:26and can be very dangerous to the data

0:28that those applications hold.

0:30So it's time to take a look at web application

0:33vulnerabilities.

0:34And we're starting with the OWASP Top 10.

0:37So what on earth is the OWASP Top 10?

0:41Well, OWASP is Open Web Application Security Project.

0:44And the 10 stands for the top 10.

0:48So we're saying, hey there, dudes and dudettes.

0:51Welcome to the OWASP Top 10.

0:53Lay back and relax and listen to the smooth jazz of web

0:59application vulnerabilities.

1:01Well, kind of like that, anyway.

1:03So it's the top 10 most common types

1:06of web app vulnerabilities.

1:10So when we've got these fantastic web apps,

1:13oftentimes they contain these vulnerabilities.

1:15We need to know about them so we can look for them,

1:17and pentest them to see if they exist

1:20or not so we can fix them and prevent

1:22those bad guys from gaining access to something

1:25they shouldn't have access to.

1:27So let's get started with number one.

1:31Number one is injection.

1:33And there are several different types of injection.

1:36And we've got some listed out down here.

1:38Some common types are SQL injection,

1:41operating system injection.

1:43That also goes along with command injection,

1:45like, your OS commands you can inject into an application.

1:49You've got LDAP, which is what Microsoft uses for its Active

1:53Directory, which is a type of database,

1:56and HTML code injection.

1:58Now, what is injection?

2:00We've got these types.

2:01But really, what is it?

2:02Well, it's just like this.

2:04It's injecting a turkey with some kind of marinade.

2:06That's what it is.

2:07Well, except the turkey is actually a web app.

2:11And this injector is not injecting a marinade.

2:14It's injecting some type of code into the application.

2:18And that's because in these applications, oftentimes

2:22there are fields where we're supposed to enter information

2:25like, I don't know, a username.

2:27And instead of entering a username,

2:28I'm going to enter some code, like, this here.

2:33And I can do all kinds of things.

2:35I'm entering code.

2:36And when I hit the Enter button down here, or Submit,

2:40it actually runs that code.

2:42The application does.

2:43Well, that's not good.

2:44It's not meant to.

2:45It's meant to accept a username into the application.

2:50Well, that sometimes doesn't work right.

2:52And these applications allow us to run scripts

2:55like a SQL command or an operating system command

2:59or inject LDAP or additional HTML code.

3:02And these are some very dangerous attacks.

3:05So how do we prevent SQL injection and operating system

3:10injection and all the other types of injections?

3:12Well, through a process called input validation.

3:15What that means is when I have that field where

3:18I enter my username and before I press that Enter button,

3:22I put some information here, maybe a script or something

3:26like that.

3:27But when I press that Enter button, what happens

3:30is the data in this field is validated.

3:33That is key-- validated.

3:35When I'm putting in a username, what

3:37do you think that username is going to contain?

3:39Well, I can dictate that in the application

3:41so that it only contains letters.

3:43Well, when I do this validation, I can say,

3:46if there is anything other than a letter in this field,

3:49don't accept it.

3:50Don't put it into my application.

3:53And that is a type of input validation.

3:56That's what it is.

3:58So we're validating the data that's

3:59being input so that we don't get special characters

4:02and things that could cause scripts

4:04to run in our applications.

4:07And that's how we prevent injection attacks

4:08by using input validation.

4:11So that was number one.

4:13On to numéro dos, broken authentication.

4:17Well, some different types of broken authentication

4:20are listed out down here.

4:22There's attacks like credential stuffing.

4:24And that's a type of brute force where

4:27we use dumps from breaches that have existed.

4:31And we try to feed them into an application in an automated

4:34fashion.

4:35So really, it's brute-forcing.

4:37That's credential stuffing.

4:38What about lack of session timeouts?

4:40So let's say I'm sitting at a computer here

4:43and I'm using a web application.

4:46And then I walk away from my computer.

4:49Well, if I don't shut that down or log out,

4:52if there's no session timeouts in there,

4:55then this application here stays running.

4:58And somebody else can walk up and use it.

5:01Well, that is a problem.

5:03That's a type of broken authentication.

5:04We need session timeouts.

5:07Well, what about lack of password storage security,

5:12meaning hashes and salts?

5:13So when I put my credentials into a web application,

5:19initially it needs to be stored somewhere, generally

5:22in a database.

5:24This is supposed to be a database here.

5:26And when it does, it shouldn't be stored as my password.

5:29It should be hashed, which is a cryptographic function.

5:33I don't want to sound overly complicated.

5:35Basically, there's a known value--

5:37we'll say a number here--

5:39and it's run through an algorithm with my password.

5:41And out comes a hashed value.

5:45And that is what should be stored in the database, not

5:48my actual password.

5:50And we can even go as far as to using something called salts.

5:53And that's instead of just a value,

5:56we add a random number in there as well so

6:02that I have two different values and that I need both of them

6:05to pull it back out from the database and use it.

6:09So that's more secure than just a hash

6:11by adding an additional salt to it

6:13or an additional random value.

6:15And those are some common types of broken authentication.

6:18Now, how do we prevent these?

6:20What can we do to prevent some of these things from happening?

6:22Well, we use password hashes and salts

6:26when we store the credentials, just like we talked

6:28about using hashes and salt.

6:30Well, what about using MFA or mutli-factor

6:34authentication so that if I have the password and the username,

6:40then that's not enough to log in?

6:43I have to have an additional type of factor, meaning,

6:47something like an app on my phone

6:50that generates a random set of numbers that I have to type in.

6:54Or it could be that I have a USB key

6:57that I need to plug into the computer,

6:59and that acts as an additional factor.

7:02Or I could do a fingerprint scanner

7:04so that it reads my fingerprint.

7:07That's a really bad fingerprint, by the way.

7:10But either way, I need an additional factor

7:12for my authentication to happen.

7:14And then lastly, of course, implementing session timeouts

7:18to improve the authentication security.

7:20So those are some ways that we can help

7:23secure broken authentication.

7:26On to number three, sensitive data exposure.

7:30And that's where sensitive data is, well, exposed.

7:34It's available to users who should not have access--

7:38we'll do grrrr--

7:39should not have access to it.

7:41So they have access into the vault

7:43to access that sensitive information.

7:45Now, some common types of sensitive data exposure

7:49or things that lead to it are unencrypted

7:52data and communications.

7:54If I am not using HTTPS, that's the trusty padlock in the web

8:00browser, then I'm not securing my communications

8:05with the web application.

8:06So if I'm sending sensitive information over the web

8:09application, it needs to be encrypted in HTTPS

8:12or SSL is one way that we can do that.

8:15The other thing is when that information is sitting

8:19on my server, and this is a server here

8:21with some hard drives in it, then it

8:23needs to be what we call encrypted,

8:26and I'll say, at rest.

8:28So that means these hard drives are encrypted.

8:31So if someone was to steal those hard drives or maybe the data

8:36was sitting on a laptop and it was left in somebody's car

8:39and it was stolen, well, they wouldn't

8:41be able to access that data because it's encrypted.

8:44Another common type is weak encryption algorithms.

8:48So maybe encryption is being used,

8:49but old, weak algorithms are being

8:52used to encrypt this data.

8:54And they can be attacked.

8:55And guess what?

8:56They can be broken.

8:57So we don't want to use old, weak encryption algorithms.

9:00Use some good stuff.

9:01Use something like AES.

9:04And lastly, we have caching of sensitive data.

9:06A lot of times, we will cache data

9:09in our apps to speed things up, to make it faster.

9:13And that way, our users have a better experience when they're

9:18trying to access their data.

9:21Well, that's not always a good idea

9:23when we're dealing with sensitive data.

9:25So we don't want to cache that sensitive data.

9:28Now, how do we prevent sensitive data exposures?

9:32So prevention-- number one is delete unnecessary data.

9:36So if we have sensitive data that's been on our system

9:39for a long time and we don't need it anymore, guess what?

9:42If we're able to, we need to check that it's OK

9:46and make sure we don't have any requirements to hold onto it.

9:49Well, we need to go ahead and trash that data because we

9:53don't need it anymore.

9:54And if we don't have it, then we can't accidentally expose it.

9:58Then we need to, of course, implement strong encryption

10:02because, as I mentioned, weak encryption algorithms can

10:04be broken, and that means the data can

10:07be read-- so strong encryption.

10:10The other thing, disable caching of our sensitive data,

10:14if that's happening.

10:15And again, we use caching to speed things up.

10:17But we do not want to cache sensitive data.

10:20And lastly, policies and procedures.

10:21We haven't talked much about that.

10:23And policies and procedures are a great way

10:26to help control sensitive data exposure because they'll

10:29let everyone know how we as a company

10:33deal with sensitive data.

10:35Do we do data classification?

10:37Which we should.

10:38And then how do we protect those different classifications

10:43of data?

10:44And how do we handle that type of data?

10:47Can we put it on external hard drives, like, USB drives?

10:51Well, probably not.

10:53So, in that case, we would have that information

10:56in our policies and procedures.

10:57And that would help protect us from sensitive data exposure.

11:01I hope we has been informative for you,

11:02and I'd like to thank you for viewing.

0:05We're continuing with the OWASP top 10.

0:09We're going to take a look at some more web application

0:11vulnerabilities.

0:12So let's jump in.

0:14Number four XML external entities or XXE.

0:19And this is what an application allows for XML input

0:22and the XML parser is not securely configured

0:26and an attacker can input commands

0:29into the XML, something like this here, and have it execute.

0:34So basically, it's like an injection,

0:36except it's an injection against XML.

0:40Now, some common types or attack types

0:42are the ability to read files from the target host

0:46or run commands on that target host.

0:49So again, it's our XML parser that's

0:52not configured just right.

0:55So how do we protect against this?

0:56Well, we disable XML external entity,

1:01which means that it's not going to accept information

1:04from external entities, like attackers trying to input data

1:08or disabled DTD processing.

1:11And that's document type definition processing,

1:14which is what can run that code and allow an attacker scripting

1:18to run against the system.

1:20And then lastly, input validation,

1:22like we've talked about before, in the injection attacks,

1:25we're validating the input.

1:27So we would go through and maybe read that XML code

1:30and look for special characters or certain clues

1:34as to identifying this as malicious code.

1:38And number five.

1:40Broken access control.

1:42Now, access control prevents people

1:44from accessing something they shouldn't have access to,

1:47right?

1:47Well, if it's broken, then that doesn't work.

1:50So they can access things they shouldn't have access to.

1:52One of the ways that this is often done

1:54is through URL modification.

1:56An example is this URL right here.

1:59And if you look under here, we have a website.com profile

2:03and then we have ID equals 586.

2:06Well, if this number here brings up information about a profile,

2:12what happens if I change that number to 302?

2:17Does it bring up another user's profile?

2:19So I can read their information?

2:21Well, that is a type of URL modification leading

2:23to access of another user's information, which

2:27is broken access control.

2:29Oftentimes, this is caused by improperly set permissions,

2:32which allows us access to data or even access

2:35to APIs, which then leads to access to data

2:39or manipulation of data.

2:41So then we lose confidentiality of our data and the integrity

2:45as well.

2:46So how do we prevent broken access control?

2:49Well, one of the things we can do

2:50is use a proper authentication mechanism,

2:54meaning our mechanisms are like role based access control.

2:59So it depends on your role as to what you have access to.

3:03And we have strong authentication this way,

3:06or we can also deny access to functions by default.

3:12And functions are like tools built into the coding language,

3:15things like maybe file.read, which would

3:20read the contents of a file.

3:22Or file.copy or things like that.

3:24Basically it's tools that are built into the coding language.

3:28And if we deny that by default, then

3:31that means we have to permit it any time

3:34we want to use it, which is fine, because that way,

3:37it's more secure.

3:38We're continuing with security misconfiguration.

3:42And believe it or not, this is the most common issue.

3:45And do you know why?

3:46I'll give you a hint.

3:47People, that's right.

3:49Because of human error.

3:51A lot of times, these common types

3:53are because of human error.

3:55And this human error can cause us lots of heartache.

3:58Now, one of these is incorrect permissions.

4:02So when we're going through and setting permissions

4:05in directories and files and subdirectories,

4:08well, if we don't set these permissions properly,

4:11a lot of times, they will flow downward

4:14through other directories and individual files.

4:17And those permissions will be incorrect.

4:19And they can lead to people having access or users

4:23having access to things they shouldn't have access to.

4:26Another problem is leaving default accounts or passwords

4:31enabled.

4:32Well, we've got to turn those off.

4:33A big OFF for the default accounts and passwords.

4:38So when there's a default account,

4:40oftentimes, we'd like to either rename

4:43that account to be something else

4:45or we just turn it off, because we don't really need it.

4:48We can create new accounts.

4:50And of course, we change all default passwords

4:53to be something very secure.

4:56Then, oftentimes, set up files and config files that are used.

5:00Specifically, a lot of times, we find them in SQL,

5:04instances like MYSQL.

5:07And we find them in like web configs,

5:10like Apache configs or Ingenix configs.

5:13We'll find where those config files are set up

5:17and we can access them through the web application,

5:20because they're a standard file and they might not

5:22have proper permissions.

5:23And those, oftentimes, will tell us

5:26about directories in use and files in use.

5:29And sometimes, even the passwords that

5:32are used by the individual applications,

5:36which is really bad if I can read that information.

5:39And then lastly, sometimes, debugging is left enabled.

5:43And we don't want that, because that

5:45means if I put some information in and it errors,

5:47instead of just telling me no, it's going to say no, because.

5:52And it's going to give me a bunch of information

5:54about the application that me, as an end user,

5:57I shouldn't have access to that information.

5:58It's going to help me if I'm an attacker

6:00to figure out how it works and how

6:02I can interact with the application

6:04and try to get more information out of it.

6:07So how do we prevent the security misconfiguration?

6:11Well, of course, number one, we need

6:13to disable any admin interfaces or at least

6:15make sure they're not accessible to anyone

6:18outside the organization.

6:19Or they're only accessible by certain IP addresses, even.

6:24And that way, there's no chance from someone

6:27from the outside being able to access an admin interface.

6:31Then we need to go in and disable or change

6:35default accounts so that they're not used anymore

6:38or we use a different name on them.

6:39And of course, we need to make sure they

6:41have a great password.

6:43We need to disable debugging so we're not giving users

6:46excessive information when they enter something wrong.

6:49And then lastly, here is a super good one.

6:52This is like my go to.

6:54How about a self audit?

6:55Why not do that?

6:57Use a scanning tool like OWASP ZAP

6:59or there's tons of others out there.

7:01Use them and scan your own environment.

7:05Look for vulnerabilities in your environment.

7:08Make sure that if you find them, then you fix them.

7:12And this is being preventative instead of responsive, right?

7:16We want to prevent these things from happening.

7:18So we don't have to be this bird with our head in the sand

7:22because we messed it up.

7:24Well, that wraps up our OS 4 through 6.

7:27I hope this has been informative for you

7:29and I'd like to thank you for viewing.

0:01[MUSIC PLAYING]

0:05We're wrapping up with the OWASP top 10.

0:08We're going to finish up with our last four web application

0:12vulnerabilities.

0:13So without any further ado, let's go.

0:18All right, number 7, cross-site scripting, oh, my, my--

0:24makes my head hurt.

0:27Well, there's actually three common types

0:29of cross-site scripting.

0:30But what is cross-site scripting?

0:33Well, in an application, sometimes, you can input data.

0:37And we've talked about this.

0:39It's an injection attack, and cross-site scripting

0:41is a form of injection attack but itself

0:45is very, very dangerous.

0:48So the idea is we can input scripts into the scripting.

0:52And, most often, this is JavaScript

0:56that we're dealing with here.

0:58So I would input a JavaScript into a field,

1:02and I would push the Enter button or Submit.

1:05And it would run that script.

1:08Now the most common way to test for this

1:11is to use a script that looks like this.

1:17And this script here, what it does

1:18is it basically create a message window or a pop up

1:21window that would say gotcha.

1:25And it's a harmless script in itself,

1:27but it's a proof of concept or POC.

1:31And it allows us to identify that cross-site scripting.

1:35It's a vulnerability within this web application.

1:37Now, as I said, there's some common types down here.

1:40There's reflected, stored, and DOM or D-O-M.

1:45And we're going to have another video, which we go over

1:48these three and more in-depth.

1:50But that is cross-site scripting.

1:51Now how do we prevent cross-site scripting?

1:54How do we do this?

1:55Well, we use input validation that we've talked about before.

1:59And, again, the input validation is validating the input

2:03that's being put into the field when it's submitted so that we

2:08can identify if this data being submitted in this field

2:13is malicious or not.

2:14And we can then prevent that data

2:17from being passed into our application and executed.

2:20The next option we have is encode data on output.

2:24And what this does is as the data is being entered

2:27into the application, when it goes in,

2:29the data is actually input into a safe form where the data is

2:35displayed and not executed.

2:38That is important.

2:39It's not executed or actually run within the application

2:42and lastly is using appropriate response headers

2:45and that's headers within the application so that this code

2:48cannot be executed.

2:50So, really, what it comes down to is find out, number one,

2:53if it's malicious or not-- that's the input validation--

2:56and then, number two, these down here encode data

3:00on output and use appropriate response

3:01headers to deal with preventing that code

3:04from being executed in case it bypasses input validation.

3:08And that's how we can prevent cross-site scripting.

3:11Then we have insecure deserialization.

3:14And what this is, basically, we have users of our applications,

3:18and that data gets stored into usually a database

3:22of some sort.

3:24And it's serialized into that database.

3:28And serialization is the process of taking that binary data--

3:33those one zeros--

3:34and converting them into strings so they

3:36can be moved around using standard protocols.

3:38And that data is stored until it's needed.

3:41Well, attackers can actually input malicious code

3:46into that serialized data.

3:48So when they input that data, it gets

3:50serialized as malicious code.

3:52But it just sits there until it's needed.

3:55Once it's needed, it's pulled from the database,

3:58and it is deserialized.

4:01And at that point, that malicious code

4:04that was inserted in there executes,

4:08and it can perform different actions,

4:10like running remote code execution or denial

4:13of service or data access.

4:16It can do all these different things.

4:18So how do we prevent insecure deserialization?

4:22Well, there's a couple different ways.

4:23Number one, don't accept untrusted data into the system,

4:27meaning from external entities.

4:28But you know what?

4:30Sometimes we can't not accept data.

4:33We've got to accept data.

4:34So that won't work for us.

4:35So in that instance, we can run deserialized data

4:39in a low-privilege environment so

4:42that the services that are deserializing the data

4:45have very little privileges.

4:46So that's all they can do.

4:48So if malicious code runs, the permissions

4:50it has from those services deserializing the data

4:55is so low that they can't do anything.

4:58So the malicious code is useless.

5:00And lastly, use strict data type constraints

5:04so that only certain data types can be used.

5:07And that's because some data types

5:09can be used to run malicious code and cause harm.

5:13So we can restrict those data types.

5:16On to number nine, using components with known

5:19vulnerabilities.

5:20Now, when we build applications or developers

5:23build applications, well, we don't reinvent the wheel.

5:27When what I mean by that is I can use pre-existing components

5:33that do things like maybe print, or they do calculations.

5:40Or I don't know.

5:40They do whatever-- do different things.

5:42They're basically tools.

5:44So when I need to build an application, I go out,

5:48and I find different tools.

5:50And I add those to my application.

5:53And I get those to do the things I need them to do.

5:57And the problem is some of these tools

6:00that get put into my applications

6:02may have vulnerabilities.

6:04So that makes my application vulnerable

6:08because if attackers configure out

6:11what tools I'm using within my application

6:14and they can scan the code for this,

6:16then they can launch attacks against my application

6:21and try to break in and grab credentials or data

6:25or cause denial of service, whatever it might be.

6:27Because these individual components or tools

6:30within my application are vulnerable.

6:33So how do we prevent this from happening?

6:36Well, number one, keep your software up-to-date,

6:38and that includes all those little tools

6:41that we use in our application, those packages.

6:43We need to keep them up-to-date.

6:46And we can run vulnerability scans

6:48using tools like OWASP ZAP to do just that, to scan it.

6:54And there's lots of other tools as well.

6:56You don't have to just use OWASP ZAP.

6:57There's a ton of different tools out there.

6:59But if we take the time to scan our applications,

7:02we can make sure that they are safe

7:04and prevent this from happening.

7:07And, finally, numero 10, we have insufficient logging

7:11and monitoring.

7:12And this, this, my friend, is something

7:15that I'm very passionate about when it comes to security.

7:18Because if we're not logging, if our systems that

7:22have users accessing it aren't outputting data into logs

7:26and we're not sending those logs into some type

7:29of serialized repository where they are stored and analyzed,

7:35we are really missing out on security

7:37and what's going on in our environment

7:40because it puts us in a situation where we have

7:42a lack of incident detection.

7:44We can't tell when something bad is going on.

7:47We can't tell when a brute force attempt is happening

7:51against our application.

7:53We can't tell when we're being scanned.

7:55We can't tell when people are trying

7:58to break into our systems using automated scanners.

8:03And all these things are easily identifiable if we're

8:06monitoring and analyzing our logs.

8:09The other thing is if an incident does

8:11happen, which it probably will, at this point,

8:14if you don't see what's going on,

8:15it's likely that you'll have an incident.

8:17And if so, you're going to have a reduced ability

8:21to investigate because you're probably not going to have any

8:23logs to look at to find out what happened.

8:26And that is bad because then if you can't find out

8:29what the root cause was and how it happened, well,

8:33how can you prevent it from happening again?

8:35That is the $10 million question.

8:38So how do we fix this problem?

8:40Well, number one, we enable proper logging

8:43within our systems.

8:44By default, a lot of systems do not properly

8:47log what they need to.

8:48So we need to enable that.

8:50Number two, use some type of serialized logging system.

8:54A seim is a great solution that you can drop all your logs

8:58into, and it will analyze it.

8:59And you can create rules and alerts.

9:01And that leads into number three, the analyzing

9:04of your logs and reporting so you can find out what's

9:07going on in your environment.

9:09And you can answer that $10 million question

9:11and, hopefully, prevent a breach from happening.

9:14That's the goal.

9:16And then, lastly, once we have this in place,

9:19we need to implement an incident response plan

9:21so that if a breach does happen, we

9:23know how to respond to that breach

9:25and secure our environment once again.

9:28And that wraps up our OWASP top 10.

9:31I hope this has been informative for you,

9:33and I'd like to thank you for viewing.

0:06Now, we've talked about injection attacks

0:09and how dangerous they can be.

0:11But one of the most common and most dangerous

0:14injection type of attacks are cross site scripting,

0:17which allows attackers to input scripting

0:19language into the application as a form of data input

0:24that is then executed and maybe even later on executed

0:27against the application and the underlying platform.

0:31So let's jump in and take a look a little deeper at cross site

0:34scripting.

0:35So there's actually three types of cross site scripting.

0:39There are reflected, stored, and DOM.

0:43So let's talk about each of these.

0:44Now, reflected.

0:45Now, earlier in a previous video,

0:47I mentioned you can input a test string that looks like this.

0:53And if you put that into the field

0:55and you press the Enter button or Submit,

0:58then you would get a pop up message that said, Gotcha.

1:02Well, this is a form of reflected cross site scripting.

1:06It is non-persistent data.

1:08So it's a script that gets run.

1:10And you get immediate feedback from the application

1:12and that is reflected.

1:14But another type is stored.

1:17And stored.

1:18The way it works is it actually stores your script here

1:22on the server.

1:24And oftentimes, this is used in blogs as part of attacks.

1:29So that in the input, you put your scripted information

1:33in there and it gets put into the blog.

1:36So somebody then visits that site and looks at your review

1:40or whatever post you had, it will actually run that script.

1:43And it can do things like run a keystroke logger

1:49or it can even steal cookies, which

1:52can be used to later on impersonate

1:55that user on that site and use it as a type of authentication.

1:59So that is stored cross site scripting.

2:02And then lastly, we have DOM.

2:04And that stands for Document Object Model.

2:07And this is part of the HTML structure

2:09and attackers can insert this code into the DOM

2:12within the HTML and that code then would be later executed

2:17at some point in time.

2:18So those are the three main types of cross site scripting,

2:21but wait, there's more.

2:24That's right.

2:25Something called cross site request forgery, CSRF or XSRF.

2:30And this stuff is really crazy.

2:33Because it attacks users unknowingly in a way

2:37that uses their credentials in whatever they're

2:40doing to attack something else.

2:42For example, let's say Frank here.

2:45Yeah.

2:46That's Frankie eating the cereal is an accountant

2:49and he works at Acme accounting.

2:52And he uses a software called ACE Accounting System.

2:58And we call this AAS.

3:00So he uses AAS, which is an online accounting system,

3:03to do his accounting and his firm does.

3:06Well, the attacker does research and figures out

3:08that Frank and his cohorts at the accounting firm use AAS.

3:14So what they do is they write up a script

3:18that will actually run within a URL that they send to Frank.

3:25Now, the idea is, Frank's always in AAS.

3:28He's in there all day, that's where he works from.

3:30So he gets an email that is a social engineering attack

3:34and it's pretty convincing .

3:35And it's got this URL in it and Frank clicks on this URL.

3:41What happens is, within this URL,

3:43is that embedded evil script.

3:46And it actually then goes out to the AAS website

3:50using Frank's credentials since he's already logged in,

3:52it doesn't have to authenticate, and it runs this evil script

3:55to do something, like maybe create a new user account.

4:01So the attackers can log in to AAS and do as they please.

4:05And this is a cross site request forgery.

4:08So it's really using a user's credentials

4:11in a forgery type of attack.

4:14And that is cross site scripting.

4:16The different types there are and how

4:18it works in upcoming videos, we'll

4:20actually be carrying out a couple of different cross site

4:23scripting attacks, so stand by.

4:25I hope this has been informative for you

4:26and I'd like to thank you for viewing.

0:00[MUSIC PLAYING]

0:05We're continuing on the theme of injection attacks.

0:08And now, we're looking at SQL injection, where

0:12we're able to inject SQL commands into a web application

0:16and have them execute within SQL and give us

0:18some type of feedback.

0:20So let's get SQL.

0:23So SQL injection attacks--

0:25well, SQL stands for Structured Query Language.

0:28And it's used with databases.

0:31Now, within a database, we need to understand a little bit

0:33about the structure of a database

0:35before we can attack it.

0:37Now, within a database, it has several tables.

0:40And I like to think of these-- they look like calendars,

0:42right, or spreadsheets.

0:44And these tables contain information.

0:46And within a table, we have columns.

0:50And those columns contain lines of data,

0:53like maybe a username or a password or a user ID.

0:59And they can contain all kinds of things.

1:01But why do we need to know this?

1:03Because if we find an application with a field that

1:09we can input data into-- here's our little Enter button

1:12or Submit--

1:13and we're able to enter some SQL commands into it

1:17and get a response, then, that means

1:20this application is susceptible to SQL injection attacks.

1:25So now, I know I can use tools like SQLmap

1:30that we're going to use in an upcoming video

1:33to attack this web application and gain

1:37access to the data within these databases,

1:40meaning the data in these tables and these columns.

1:44Now, how exactly can we test for SQL injection?

1:47Well, you can use an automated scanner to test for it.

1:50Or let's say this is the field here.

1:53What I can do is enter a SQL command-- in a very simple one.

1:56It's a single quote, a space, the word

1:59"or," another space, the number 1 equals the number

2:041, another space, two dashes, and then a final space.

2:09Now, what this does--

2:11the single tick mark here, or single quote,

2:13tells SQL this is the end or beginning of a new action.

2:18So basically, it says this is a new action.

2:20I want you to run it.

2:22And the way SQL handles this is it's

2:24looking to see if something is true or false.

2:28And it will reply accordingly.

2:30It'll respond with specific date of it's false, or other date

2:33if it's true.

2:34So what we're telling SQL here is equals 1, which is true,

2:40of course.

2:41So then, the idea is, if this is a username field,

2:44I'm telling SQL that I entered a correct username or correct

2:49password, because this is true.

2:51And that's the way this command works.

2:53It's just a simple test to see if this field is

2:56susceptible to SQL injection.

2:58Now, if I enter this command here,

3:01and I get information back that I shouldn't,

3:03like a list of usernames or IDs or something,

3:06then I know I can use it to like SQLmap

3:09to go ahead and do further testing against the database.

3:13And that's where I'm going to be looking

3:15for a list of the databases that exist on that server.

3:20And then, I'm going to look for a list of the tables that

3:23exist in that database.

3:25Then, I'm going to move on to the columns within that table.

3:29And then lastly, I want to pull, or we refer to it

3:32as dump that column of usernames or passwords or IDs

3:38or whatever is in there, at which point,

3:40I have a copy of that data.

3:42And I could even-- if I wanted to

3:44though, I could do other things than just dump that data.

3:47I could actually update the data in the database

3:51to do things like maybe change the price of something

3:54if I wanted to, or change somebody's password.

3:56You know, for instance, if there's

3:57something I wanted to buy in this online store

3:59and I have access to the database, well,

4:02I could change the price of something in the database

4:05and then go online and buy it at that reduced cost.

4:09And there you go.

4:10That is SQL injection attacks and how they work.

4:13And, again in upcoming videos, we're

4:15going to perform SQL injection attacks to pull the usernames

4:19and passwords out of an application's database.

4:22I hope this has been informative for you.

4:23And I'd like to thank you for viewing.

0:00[MUSIC PLAYING]

0:06It's time to talk about a new type of web application

0:09vulnerability dealing with the ability

0:12to traverse directories and open files on that local file

0:17system of the web application server,

0:19and even load files off of another server.

0:24Ooh, sounds interesting.

0:26Let's get started.

0:28So we're starting off with a directory traversal

0:30vulnerability.

0:31And that means that I, as a web application user,

0:34can traverse directories and actually

0:38load files from directories that I shouldn't be able to.

0:41And the way this works is through URL manipulation.

0:46I'm going to manipulate this URL right here.

0:50And if you see, it's http://mydomain.com/?value.

0:55Now, generally this would be filled in

0:57by the web application itself with something

1:00like, I don't know, "baked apple" or something, whatever

1:03that value might be, because that's information you put in

1:07within the web application.

1:08You submitted some information or something

1:10or clicked buttons.

1:11And it autofilled this in.

1:13But what if I was to instead of put that in there,

1:17I put something else, such as the path to a file, like,

1:21"../"?

1:23Now, ../ means If I have a directory structure

1:26and I'm sitting right here, if I do a ../,

1:30it means go up one directory or go back one directory.

1:33So I would go to this one.

1:34And if I did another ../, I would go to this one.

1:37And the idea is when I use dot dot slashes,

1:40I'm trying to get back to the root of the file system.

1:43And that way, I can go up from there

1:46because I know the file structure of that system

1:49because it's standardized.

1:50So I could do a ../ again.

1:52I could put a couple of these in to make

1:54sure I get back to root.

1:55And then I can put in etc/passwd on a Linux host.

2:02And if I hit Enter at that point, it may--

2:06we'll put it this way, if the directory traversal

2:08vulnerability exists, it will show me the contents

2:12of the etc/passwd file.

2:13Now, this doesn't contain the passwords to the system.

2:16But it does contain a list of users and some information

2:20about their local profile.

2:23So I could get a list of all the users on that host.

2:26But I could do other things.

2:27I could probably load other files, not just this one.

2:31I would want to look for, maybe, Apache config files

2:35or look for other types of config files.

2:39Maybe I'd even want to try to load something like a bash

2:44history file from a user, which contains all of the commands

2:49that they've run recently in their command prompt and bash.

2:55Now, the downside to this attack is

2:57you do have to know where the files exist within the file

3:01system.

3:02You can't do, like, an LS to list all the files out,

3:05or in Windows, a DIR to list the files.

3:08You have to know that they exist and where they're at.

3:10So that's why we look for known values, like,

3:13the etc/passwd or config files.

3:15Ooh, we also definitely look for log

3:17files as well because log files contain lots of information.

3:21And this is a directory traversal vulnerability.

3:26Next up is a local file inclusion

3:29vulnerability, which is similar to directory traversal

3:33because when I tell you what it does,

3:35you're going to say, well, that's the same thing

3:37as directory traversal.

3:38Well, not exactly because, again, if I put in a ../../,

3:45and I put some of these in, and I load the etc/passwd file,

3:50and it works, and I have this local file inclusion, well,

3:54I just did that in the directory traversal.

3:55The difference is, with an LFI, it actually

3:59executes the code that's in this file,

4:03if there were any, because a directory traversal does not

4:07do that.

4:07So the big key difference here is the ability to run code,

4:11because if I loaded a script--

4:13I went, like, ../../, and I put a script .sh,

4:20which is a bash script, and I ran that,

4:23the LFI would actually run the script,

4:25whereas a directory traversal would not run this script.

4:30It would probably show me the contents of the file,

4:32but it wouldn't actually run it as a script.

4:35But a Local File Inclusion will run the content as a script.

4:38So at this point, we still have to know where the files exist.

4:43We don't get to run commands, like, LS or DIR or change

4:48directory or anything like that.

4:50We have to tell it a single file.

4:52But where does this come in handy?

4:54Here's where it comes in handy.

4:56Oftentimes, we can find ways through file uploads

5:01within an application where we can

5:04upload a file to this server.

5:07Well, if we can do that, then we can use the LFI to reference

5:11the file we uploaded.

5:12And one of the types of files we can upload

5:14is called a web shell.

5:17And this is a web page that has tools

5:21built for us as pentesters, tools like,

5:24run commands so that we can run an additional command.

5:28We can run these LS and DIR and CD and tools to download files.

5:34So we can exfiltrate data from that server.

5:38And there's lots of different things

5:40we can do with web shells.

5:42And by default, in Kali Linux that we use for pentesting,

5:46web shells are located in /USR/share/webshells.

5:56And under that directory, you're going

5:58to see other directories, like, php and other coding

6:02languages because web shells come in different languages.

6:07So that is where we could use web shells and local file

6:11inclusion to really own a box, because of the vulnerabilities.

6:14Then we have remote file inclusion.

6:17If you thought local file inclusion was cool,

6:19wait till you get a load of this thing.

6:21Now, here, instead of a value of a local file, like, ../../,

6:27we wouldn't do that.

6:28What we would do is put a URL in here

6:31and reference a file on another server.

6:34So we put http:slash,slash 192.168.1.103 slash

6:43webshell.txt.

6:47And what would happen is the system

6:50would actually go to that file, read that information,

6:54and run it against the web application server.

6:58Now, this could be a web shell, like I said there.

7:00Or it could be an exploit for a known vulnerability.

7:06Or it could be a script that gets me a shell on the target

7:13host that's running the web application,

7:16because the fact is, I own this server.

7:20This one right here, this 192.168

7:22that's going to be my attacker box or a server I own.

7:25So I can put whatever I want to on there.

7:27I just tell this host via this remote file inclusion,

7:31go to my server, get that file, and run the thing already.

7:35So that is super dangerous because I

7:37can do pretty much anything I want to,

7:40encoding, and attack this host and do all kinds of things.

7:44That's why remote file inclusions

7:46are even more scary than the LFIs and the directory

7:50traversal.

7:51So these have been some great vulnerabilities

7:53to talk with you about as far as web applications.

7:57And we're going to be exploiting these in some upcoming videos.

8:00So stay with us.

8:01I hope this has been informative for you,

8:03and I'd like to thank you for viewing.

0:06We're wrapping up our web application vulnerabilities

0:10by going through some various attacks, including clickjacking

0:15and brute force.

0:16So here we go.

0:18So we're starting with clickjacking.

0:20That's a cool name.

0:21So what is clickjacking?

0:23Well, when you visit a web page, there's

0:26lots of pictures and things on the page.

0:30There's images.

0:32There's mountain peaks.

0:33The sun's shining in it.

0:35And there's other things, too.

0:36There are articles with information.

0:39You know, there's all kinds of things--

0:41and titles-- on these web pages.

0:43Well, clickjacking is when an attacker uses a transparent

0:48field on a website.

0:50And so basically, they put this field over something

0:53that you're going to click on.

0:55But this transparent field contains some code.

0:59So when you click on it, you're not actually

1:01clicking on the underlying link.

1:03You're not at all.

1:04You're clicking on the data or the scripting

1:07in the transparent field that's there.

1:09So you're kind of being hijacked at that point.

1:12And that is known as clickjacking.

1:14And it relies on the transparent field,

1:16and it actually runs in iframes.

1:19And in order to prevent this, you

1:21can set your x-frame options to use a Deny response

1:25header, which will prevent the iframes from being

1:28used on the page.

1:30And that is clickjacking.

1:33Then we have brute force attacks.

1:37This guy looks like he could brute

1:38force into several things.

1:40So brute force attack is when we have a website or web

1:44application, and somewhere in it-- usually,

1:47this is brute forcing credentials.

1:49So you've got username and password here.

1:51And so what a brute force attack does

1:54is it uses a tool or script to run through and use,

1:59generally, a given username, like admin.

2:04And then it will use a password file,

2:09which is just a file that contains

2:11a whole bunch of possible passwords, maybe thousands

2:15upon thousands of them.

2:16And your brute force tool is going

2:18to go out and try all of these different passwords

2:22with the username that you supply.

2:24Now you can do a brute force where

2:27you use a file for both the username and the password.

2:30So it'll go through and test all the different usernames

2:33and password combinations to try to brute force

2:36your way into this web application or website.

2:40How do we prevent this?

2:41Well, we have to implement account lockout,

2:44so that an account will lock out after so many failed log

2:49attempts.

2:49Like three or four failed login attempts,

2:51and it'll lock for 15 minutes, and then auto-unlock.

2:55So an account lockout is how we can prevent that

2:59from happening.

3:00The other thing is we want to make

3:01sure we have appropriate logging that's

3:03happening in our applications and on our servers,

3:05and that we're analyzing those logs,

3:09so we can see these attacks happening.

3:11And then we can block those types of attacks.

3:15Then we have session Hijacking and this is actually

3:18pretty interesting.

3:20Session hijacking is when we try to steal a cookie, which

3:27contains a session ID.

3:30This session ID contains authentication information

3:35that we can use to impersonate the user.

3:40So if I was just able to steal a cookie--

3:43and that could come from the web app server itself,

3:47or could come from the user's browser window, either one--

3:52then I could impersonate that user, and login

3:56to whatever that web application or website is.

3:59And I get hijack that session and gain access to it.

4:02One way to steal cookies is to do it via cross-site scripting

4:06vulnerabilities.

4:07And we're going to look at how to do

4:08that in an upcoming video, which is pretty darn interesting.

4:14And we're wrapping up with redirects.

4:17Redirects-- as you can see in this URL here,

4:19we got mybank.com/example.php?

4:23And then we see another URL, and this is a redirect.

4:26This is often used in social engineering attacks.

4:31So the idea is if I was to--

4:33as a bad guy, I'm sending a social engineering attack.

4:37Let's say a phishing email.

4:38And it contains this URL.

4:41Well, I'm probably going to use something called obfuscation

4:44in this URL piece that's circled right here

4:47so that this looks different.

4:48It doesn't actually look like a URL.

4:50Obfuscation can encode this information here.

4:54A popular type is called base64 encoding.

4:58And that way, it looks like there's

4:59a string of random characters and not a URL.

5:02But if I was to insert this into here,

5:05and send it to my happy-go-lucky target here,

5:09and this happy-go-lucky target clicks on that link

5:14and goes to it, well, they're actually

5:16going to the real mybank.com.

5:20But they're then being redirected to this URL.

5:23And so when they hit that site, that's something

5:25they recognize.

5:26And if you look at just this URL,

5:28and that is the standard URL for your bank,

5:31then it's hard to detect a phishing attack.

5:34It's hard to detect that social engineering.

5:37So how do we prevent this?

5:38Well, that actually goes back to whoever owns this website.

5:43That's the person that has to do this.

5:45And they do this by not allowing redirects

5:49and forwards in the web configs of their website.

5:54So if you were to hit their site,

5:56and it sees this redirect, it would not allow it to happen.

5:59But some sites have to allow it to happen

6:02for the way they work.

6:03Well, in that case, oftentimes, you'll

6:05see a warning page that says, "You are leaving."

6:12And then that way, you know you're being

6:15redirected to somewhere else.

6:17And that is redirect.

6:19And that wraps up these vulnerabilities and attacks.

6:21I hope this has been informative for you,

6:23and I'd like to thank you for viewing.