Web Application Vulnerabilities

0:05Most of us use web applications every day. I'm talking about, like, online banking. And who does their grocery shopping online? Who uses Amazon? I mean, webmail, all these things are web-based applications. And many of them have vulnerabilities in them that can be exploited and attacked and can be very dangerous to the data that those applications hold. So it's time to take a look at web application vulnerabilities. And we're starting with the OWASP Top 10.

0:37So what on earth is the OWASP Top 10? Well, OWASP is Open Web Application Security Project. And the 10 stands for the top 10. So we're saying, hey there, dudes and dudettes. Welcome to the OWASP Top 10. Lay back and relax and listen to the smooth jazz of web application vulnerabilities. Well, kind of like that, anyway. So it's the top 10 most common types of web app vulnerabilities.

1:10So when we've got these fantastic web apps, oftentimes they contain these vulnerabilities. We need to know about them so we can look for them, and pentest them to see if they exist or not so we can fix them and prevent those bad guys from gaining access to something they shouldn't have access to. So let's get started with number one. Number one is injection. And there are several different types of injection. And we've got some listed out down here. Some common types are SQL injection, operating system injection.

1:43That also goes along with command injection, like, your OS commands you can inject into an application. You've got LDAP, which is what Microsoft uses for its Active Directory, which is a type of database, and HTML code injection. Now, what is injection? We've got these types. But really, what is it? Well, it's just like this. It's injecting a turkey with some kind of marinade. That's what it is. Well, except the turkey is actually a web app. And this injector is not injecting a marinade.

2:14It's injecting some type of code into the application. And that's because in these applications, oftentimes there are fields where we're supposed to enter information like, I don't know, a username. And instead of entering a username, I'm going to enter some code, like, this here. And I can do all kinds of things. I'm entering code. And when I hit the Enter button down here, or Submit, it actually runs that code. The application does. Well, that's not good. It's not meant to.

2:45It's meant to accept a username into the application. Well, that sometimes doesn't work right. And these applications allow us to run scripts like a SQL command or an operating system command or inject LDAP or additional HTML code. And these are some very dangerous attacks. So how do we prevent SQL injection and operating system injection and all the other types of injections? Well, through a process called input validation.

3:15What that means is when I have that field where I enter my username and before I press that Enter button, I put some information here, maybe a script or something like that. But when I press that Enter button, what happens is the data in this field is validated. That is key-- validated. When I'm putting in a username, what do you think that username is going to contain? Well, I can dictate that in the application so that it only contains letters. Well, when I do this validation, I can say, if there is anything other than a letter in this field, don't accept it.

3:50Don't put it into my application. And that is a type of input validation. That's what it is. So we're validating the data that's being input so that we don't get special characters and things that could cause scripts to run in our applications. And that's how we prevent injection attacks by using input validation. So that was number one. On to numéro dos, broken authentication. Well, some different types of broken authentication are listed out down here.

4:22There's attacks like credential stuffing. And that's a type of brute force where we use dumps from breaches that have existed. And we try to feed them into an application in an automated fashion. So really, it's brute-forcing. That's credential stuffing. What about lack of session timeouts? So let's say I'm sitting at a computer here and I'm using a web application. And then I walk away from my computer. Well, if I don't shut that down or log out, if there's no session timeouts in there, then this application here stays running.

4:58And somebody else can walk up and use it. Well, that is a problem. That's a type of broken authentication. We need session timeouts. Well, what about lack of password storage security, meaning hashes and salts? So when I put my credentials into a web application, initially it needs to be stored somewhere, generally in a database. This is supposed to be a database here. And when it does, it shouldn't be stored as my password.

5:29It should be hashed, which is a cryptographic function. I don't want to sound overly complicated. Basically, there's a known value-- we'll say a number here-- and it's run through an algorithm with my password. And out comes a hashed value. And that is what should be stored in the database, not my actual password. And we can even go as far as to using something called salts. And that's instead of just a value, we add a random number in there as well so that I have two different values and that I need both of them to pull it back out from the database and use it.

6:09So that's more secure than just a hash by adding an additional salt to it or an additional random value. And those are some common types of broken authentication. Now, how do we prevent these? What can we do to prevent some of these things from happening? Well, we use password hashes and salts when we store the credentials, just like we talked about using hashes and salt. Well, what about using MFA or mutli-factor authentication so that if I have the password and the username, then that's not enough to log in?

6:43I have to have an additional type of factor, meaning, something like an app on my phone that generates a random set of numbers that I have to type in. Or it could be that I have a USB key that I need to plug into the computer, and that acts as an additional factor. Or I could do a fingerprint scanner so that it reads my fingerprint. That's a really bad fingerprint, by the way. But either way, I need an additional factor for my authentication to happen.

7:14And then lastly, of course, implementing session timeouts to improve the authentication security. So those are some ways that we can help secure broken authentication. On to number three, sensitive data exposure. And that's where sensitive data is, well, exposed. It's available to users who should not have access-- we'll do grrrr-- should not have access to it. So they have access into the vault to access that sensitive information.

7:45Now, some common types of sensitive data exposure or things that lead to it are unencrypted data and communications. If I am not using HTTPS, that's the trusty padlock in the web browser, then I'm not securing my communications with the web application. So if I'm sending sensitive information over the web application, it needs to be encrypted in HTTPS or SSL is one way that we can do that. The other thing is when that information is sitting on my server, and this is a server here with some hard drives in it, then it needs to be what we call encrypted, and I'll say, at rest.

8:28So that means these hard drives are encrypted. So if someone was to steal those hard drives or maybe the data was sitting on a laptop and it was left in somebody's car and it was stolen, well, they wouldn't be able to access that data because it's encrypted. Another common type is weak encryption algorithms. So maybe encryption is being used, but old, weak algorithms are being used to encrypt this data. And they can be attacked. And guess what? They can be broken. So we don't want to use old, weak encryption algorithms.

9:00Use some good stuff. Use something like AES. And lastly, we have caching of sensitive data. A lot of times, we will cache data in our apps to speed things up, to make it faster. And that way, our users have a better experience when they're trying to access their data. Well, that's not always a good idea when we're dealing with sensitive data. So we don't want to cache that sensitive data. Now, how do we prevent sensitive data exposures?

9:32So prevention-- number one is delete unnecessary data. So if we have sensitive data that's been on our system for a long time and we don't need it anymore, guess what? If we're able to, we need to check that it's OK and make sure we don't have any requirements to hold onto it. Well, we need to go ahead and trash that data because we don't need it anymore. And if we don't have it, then we can't accidentally expose it. Then we need to, of course, implement strong encryption because, as I mentioned, weak encryption algorithms can be broken, and that means the data can be read-- so strong encryption.

10:10The other thing, disable caching of our sensitive data, if that's happening. And again, we use caching to speed things up. But we do not want to cache sensitive data. And lastly, policies and procedures. We haven't talked much about that. And policies and procedures are a great way to help control sensitive data exposure because they'll let everyone know how we as a company deal with sensitive data. Do we do data classification? Which we should. And then how do we protect those different classifications of data?

10:44And how do we handle that type of data? Can we put it on external hard drives, like, USB drives? Well, probably not. So, in that case, we would have that information in our policies and procedures. And that would help protect us from sensitive data exposure. I hope we has been informative for you, and I'd like to thank you for viewing.

0:05We're continuing with the OWASP top 10. We're going to take a look at some more web application vulnerabilities. So let's jump in. Number four XML external entities or XXE. And this is what an application allows for XML input and the XML parser is not securely configured and an attacker can input commands into the XML, something like this here, and have it execute. So basically, it's like an injection, except it's an injection against XML.

0:40Now, some common types or attack types are the ability to read files from the target host or run commands on that target host. So again, it's our XML parser that's not configured just right. So how do we protect against this? Well, we disable XML external entity, which means that it's not going to accept information from external entities, like attackers trying to input data or disabled DTD processing.

1:11And that's document type definition processing, which is what can run that code and allow an attacker scripting to run against the system. And then lastly, input validation, like we've talked about before, in the injection attacks, we're validating the input. So we would go through and maybe read that XML code and look for special characters or certain clues as to identifying this as malicious code. And number five. Broken access control.

1:42Now, access control prevents people from accessing something they shouldn't have access to, right? Well, if it's broken, then that doesn't work. So they can access things they shouldn't have access to. One of the ways that this is often done is through URL modification. An example is this URL right here. And if you look under here, we have a website.com profile and then we have ID equals 586. Well, if this number here brings up information about a profile, what happens if I change that number to 302?

2:17Does it bring up another user's profile? So I can read their information? Well, that is a type of URL modification leading to access of another user's information, which is broken access control. Oftentimes, this is caused by improperly set permissions, which allows us access to data or even access to APIs, which then leads to access to data or manipulation of data. So then we lose confidentiality of our data and the integrity as well. So how do we prevent broken access control?

2:49Well, one of the things we can do is use a proper authentication mechanism, meaning our mechanisms are like role based access control. So it depends on your role as to what you have access to. And we have strong authentication this way, or we can also deny access to functions by default. And functions are like tools built into the coding language, things like maybe file.read, which would read the contents of a file.

3:22Or file.copy or things like that. Basically it's tools that are built into the coding language. And if we deny that by default, then that means we have to permit it any time we want to use it, which is fine, because that way, it's more secure. We're continuing with security misconfiguration. And believe it or not, this is the most common issue. And do you know why? I'll give you a hint. People, that's right. Because of human error. A lot of times, these common types are because of human error.

3:55And this human error can cause us lots of heartache. Now, one of these is incorrect permissions. So when we're going through and setting permissions in directories and files and subdirectories, well, if we don't set these permissions properly, a lot of times, they will flow downward through other directories and individual files. And those permissions will be incorrect. And they can lead to people having access or users having access to things they shouldn't have access to.

4:26Another problem is leaving default accounts or passwords enabled. Well, we've got to turn those off. A big OFF for the default accounts and passwords. So when there's a default account, oftentimes, we'd like to either rename that account to be something else or we just turn it off, because we don't really need it. We can create new accounts. And of course, we change all default passwords to be something very secure. Then, oftentimes, set up files and config files that are used.

5:00Specifically, a lot of times, we find them in SQL, instances like MYSQL. And we find them in like web configs, like Apache configs or Ingenix configs. We'll find where those config files are set up and we can access them through the web application, because they're a standard file and they might not have proper permissions. And those, oftentimes, will tell us about directories in use and files in use. And sometimes, even the passwords that are used by the individual applications, which is really bad if I can read that information.

5:39And then lastly, sometimes, debugging is left enabled. And we don't want that, because that means if I put some information in and it errors, instead of just telling me no, it's going to say no, because. And it's going to give me a bunch of information about the application that me, as an end user, I shouldn't have access to that information. It's going to help me if I'm an attacker to figure out how it works and how I can interact with the application and try to get more information out of it. So how do we prevent the security misconfiguration?

6:11Well, of course, number one, we need to disable any admin interfaces or at least make sure they're not accessible to anyone outside the organization. Or they're only accessible by certain IP addresses, even. And that way, there's no chance from someone from the outside being able to access an admin interface. Then we need to go in and disable or change default accounts so that they're not used anymore or we use a different name on them. And of course, we need to make sure they have a great password.

6:43We need to disable debugging so we're not giving users excessive information when they enter something wrong. And then lastly, here is a super good one. This is like my go to. How about a self audit? Why not do that? Use a scanning tool like OWASP ZAP or there's tons of others out there. Use them and scan your own environment. Look for vulnerabilities in your environment. Make sure that if you find them, then you fix them. And this is being preventative instead of responsive, right?

7:16We want to prevent these things from happening. So we don't have to be this bird with our head in the sand because we messed it up. Well, that wraps up our OS 4 through 6. I hope this has been informative for you and I'd like to thank you for viewing.

0:01[MUSIC PLAYING] We're wrapping up with the OWASP top 10. We're going to finish up with our last four web application vulnerabilities. So without any further ado, let's go. All right, number 7, cross-site scripting, oh, my, my-- makes my head hurt. Well, there's actually three common types of cross-site scripting. But what is cross-site scripting?

0:33Well, in an application, sometimes, you can input data. And we've talked about this. It's an injection attack, and cross-site scripting is a form of injection attack but itself is very, very dangerous. So the idea is we can input scripts into the scripting. And, most often, this is JavaScript that we're dealing with here. So I would input a JavaScript into a field, and I would push the Enter button or Submit.

1:05And it would run that script. Now the most common way to test for this is to use a script that looks like this. And this script here, what it does is it basically create a message window or a pop up window that would say gotcha. And it's a harmless script in itself, but it's a proof of concept or POC. And it allows us to identify that cross-site scripting. It's a vulnerability within this web application.

1:37Now, as I said, there's some common types down here. There's reflected, stored, and DOM or D-O-M. And we're going to have another video, which we go over these three and more in-depth. But that is cross-site scripting. Now how do we prevent cross-site scripting? How do we do this? Well, we use input validation that we've talked about before. And, again, the input validation is validating the input that's being put into the field when it's submitted so that we can identify if this data being submitted in this field is malicious or not.

2:14And we can then prevent that data from being passed into our application and executed. The next option we have is encode data on output. And what this does is as the data is being entered into the application, when it goes in, the data is actually input into a safe form where the data is displayed and not executed. That is important. It's not executed or actually run within the application and lastly is using appropriate response headers and that's headers within the application so that this code cannot be executed.

2:50So, really, what it comes down to is find out, number one, if it's malicious or not-- that's the input validation-- and then, number two, these down here encode data on output and use appropriate response headers to deal with preventing that code from being executed in case it bypasses input validation. And that's how we can prevent cross-site scripting. Then we have insecure deserialization. And what this is, basically, we have users of our applications, and that data gets stored into usually a database of some sort.

3:24And it's serialized into that database. And serialization is the process of taking that binary data-- those one zeros-- and converting them into strings so they can be moved around using standard protocols. And that data is stored until it's needed. Well, attackers can actually input malicious code into that serialized data. So when they input that data, it gets serialized as malicious code. But it just sits there until it's needed.

3:55Once it's needed, it's pulled from the database, and it is deserialized. And at that point, that malicious code that was inserted in there executes, and it can perform different actions, like running remote code execution or denial of service or data access. It can do all these different things. So how do we prevent insecure deserialization? Well, there's a couple different ways. Number one, don't accept untrusted data into the system, meaning from external entities.

4:28But you know what? Sometimes we can't not accept data. We've got to accept data. So that won't work for us. So in that instance, we can run deserialized data in a low-privilege environment so that the services that are deserializing the data have very little privileges. So that's all they can do. So if malicious code runs, the permissions it has from those services deserializing the data is so low that they can't do anything. So the malicious code is useless.

5:00And lastly, use strict data type constraints so that only certain data types can be used. And that's because some data types can be used to run malicious code and cause harm. So we can restrict those data types. On to number nine, using components with known vulnerabilities. Now, when we build applications or developers build applications, well, we don't reinvent the wheel. When what I mean by that is I can use pre-existing components that do things like maybe print, or they do calculations.

5:40Or I don't know. They do whatever-- do different things. They're basically tools. So when I need to build an application, I go out, and I find different tools. And I add those to my application. And I get those to do the things I need them to do. And the problem is some of these tools that get put into my applications may have vulnerabilities. So that makes my application vulnerable because if attackers configure out what tools I'm using within my application and they can scan the code for this, then they can launch attacks against my application and try to break in and grab credentials or data or cause denial of service, whatever it might be.

6:27Because these individual components or tools within my application are vulnerable. So how do we prevent this from happening? Well, number one, keep your software up-to-date, and that includes all those little tools that we use in our application, those packages. We need to keep them up-to-date. And we can run vulnerability scans using tools like OWASP ZAP to do just that, to scan it. And there's lots of other tools as well. You don't have to just use OWASP ZAP.

6:57There's a ton of different tools out there. But if we take the time to scan our applications, we can make sure that they are safe and prevent this from happening. And, finally, numero 10, we have insufficient logging and monitoring. And this, this, my friend, is something that I'm very passionate about when it comes to security. Because if we're not logging, if our systems that have users accessing it aren't outputting data into logs and we're not sending those logs into some type of serialized repository where they are stored and analyzed, we are really missing out on security and what's going on in our environment because it puts us in a situation where we have a lack of incident detection.

7:44We can't tell when something bad is going on. We can't tell when a brute force attempt is happening against our application. We can't tell when we're being scanned. We can't tell when people are trying to break into our systems using automated scanners. And all these things are easily identifiable if we're monitoring and analyzing our logs. The other thing is if an incident does happen, which it probably will, at this point, if you don't see what's going on, it's likely that you'll have an incident.

8:17And if so, you're going to have a reduced ability to investigate because you're probably not going to have any logs to look at to find out what happened. And that is bad because then if you can't find out what the root cause was and how it happened, well, how can you prevent it from happening again? That is the $10 million question. So how do we fix this problem? Well, number one, we enable proper logging within our systems. By default, a lot of systems do not properly log what they need to.

8:48So we need to enable that. Number two, use some type of serialized logging system. A seim is a great solution that you can drop all your logs into, and it will analyze it. And you can create rules and alerts. And that leads into number three, the analyzing of your logs and reporting so you can find out what's going on in your environment. And you can answer that $10 million question and, hopefully, prevent a breach from happening. That's the goal. And then, lastly, once we have this in place, we need to implement an incident response plan so that if a breach does happen, we know how to respond to that breach and secure our environment once again.

9:28And that wraps up our OWASP top 10. I hope this has been informative for you, and I'd like to thank you for viewing.

0:06Now, we've talked about injection attacks and how dangerous they can be. But one of the most common and most dangerous injection type of attacks are cross site scripting, which allows attackers to input scripting language into the application as a form of data input that is then executed and maybe even later on executed against the application and the underlying platform. So let's jump in and take a look a little deeper at cross site scripting. So there's actually three types of cross site scripting.

0:39There are reflected, stored, and DOM. So let's talk about each of these. Now, reflected. Now, earlier in a previous video, I mentioned you can input a test string that looks like this. And if you put that into the field and you press the Enter button or Submit, then you would get a pop up message that said, Gotcha. Well, this is a form of reflected cross site scripting. It is non-persistent data. So it's a script that gets run.

1:10And you get immediate feedback from the application and that is reflected. But another type is stored. And stored. The way it works is it actually stores your script here on the server. And oftentimes, this is used in blogs as part of attacks. So that in the input, you put your scripted information in there and it gets put into the blog. So somebody then visits that site and looks at your review or whatever post you had, it will actually run that script.

1:43And it can do things like run a keystroke logger or it can even steal cookies, which can be used to later on impersonate that user on that site and use it as a type of authentication. So that is stored cross site scripting. And then lastly, we have DOM. And that stands for Document Object Model. And this is part of the HTML structure and attackers can insert this code into the DOM within the HTML and that code then would be later executed at some point in time.

2:18So those are the three main types of cross site scripting, but wait, there's more. That's right. Something called cross site request forgery, CSRF or XSRF. And this stuff is really crazy. Because it attacks users unknowingly in a way that uses their credentials in whatever they're doing to attack something else. For example, let's say Frank here. Yeah. That's Frankie eating the cereal is an accountant and he works at Acme accounting.

2:52And he uses a software called ACE Accounting System. And we call this AAS. So he uses AAS, which is an online accounting system, to do his accounting and his firm does. Well, the attacker does research and figures out that Frank and his cohorts at the accounting firm use AAS. So what they do is they write up a script that will actually run within a URL that they send to Frank.

3:25Now, the idea is, Frank's always in AAS. He's in there all day, that's where he works from. So he gets an email that is a social engineering attack and it's pretty convincing . And it's got this URL in it and Frank clicks on this URL. What happens is, within this URL, is that embedded evil script. And it actually then goes out to the AAS website using Frank's credentials since he's already logged in, it doesn't have to authenticate, and it runs this evil script to do something, like maybe create a new user account.

4:01So the attackers can log in to AAS and do as they please. And this is a cross site request forgery. So it's really using a user's credentials in a forgery type of attack. And that is cross site scripting. The different types there are and how it works in upcoming videos, we'll actually be carrying out a couple of different cross site scripting attacks, so stand by. I hope this has been informative for you and I'd like to thank you for viewing.

0:00[MUSIC PLAYING] We're continuing on the theme of injection attacks. And now, we're looking at SQL injection, where we're able to inject SQL commands into a web application and have them execute within SQL and give us some type of feedback. So let's get SQL. So SQL injection attacks-- well, SQL stands for Structured Query Language. And it's used with databases.

0:31Now, within a database, we need to understand a little bit about the structure of a database before we can attack it. Now, within a database, it has several tables. And I like to think of these-- they look like calendars, right, or spreadsheets. And these tables contain information. And within a table, we have columns. And those columns contain lines of data, like maybe a username or a password or a user ID. And they can contain all kinds of things.

1:01But why do we need to know this? Because if we find an application with a field that we can input data into-- here's our little Enter button or Submit-- and we're able to enter some SQL commands into it and get a response, then, that means this application is susceptible to SQL injection attacks. So now, I know I can use tools like SQLmap that we're going to use in an upcoming video to attack this web application and gain access to the data within these databases, meaning the data in these tables and these columns.

1:44Now, how exactly can we test for SQL injection? Well, you can use an automated scanner to test for it. Or let's say this is the field here. What I can do is enter a SQL command-- in a very simple one. It's a single quote, a space, the word "or," another space, the number 1 equals the number 1, another space, two dashes, and then a final space. Now, what this does-- the single tick mark here, or single quote, tells SQL this is the end or beginning of a new action.

2:18So basically, it says this is a new action. I want you to run it. And the way SQL handles this is it's looking to see if something is true or false. And it will reply accordingly. It'll respond with specific date of it's false, or other date if it's true. So what we're telling SQL here is equals 1, which is true, of course. So then, the idea is, if this is a username field, I'm telling SQL that I entered a correct username or correct password, because this is true.

2:51And that's the way this command works. It's just a simple test to see if this field is susceptible to SQL injection. Now, if I enter this command here, and I get information back that I shouldn't, like a list of usernames or IDs or something, then I know I can use it to like SQLmap to go ahead and do further testing against the database. And that's where I'm going to be looking for a list of the databases that exist on that server. And then, I'm going to look for a list of the tables that exist in that database.

3:25Then, I'm going to move on to the columns within that table. And then lastly, I want to pull, or we refer to it as dump that column of usernames or passwords or IDs or whatever is in there, at which point, I have a copy of that data. And I could even-- if I wanted to though, I could do other things than just dump that data. I could actually update the data in the database to do things like maybe change the price of something if I wanted to, or change somebody's password.

3:56You know, for instance, if there's something I wanted to buy in this online store and I have access to the database, well, I could change the price of something in the database and then go online and buy it at that reduced cost. And there you go. That is SQL injection attacks and how they work. And, again in upcoming videos, we're going to perform SQL injection attacks to pull the usernames and passwords out of an application's database. I hope this has been informative for you. And I'd like to thank you for viewing.

0:00[MUSIC PLAYING] It's time to talk about a new type of web application vulnerability dealing with the ability to traverse directories and open files on that local file system of the web application server, and even load files off of another server. Ooh, sounds interesting. Let's get started. So we're starting off with a directory traversal vulnerability.

0:31And that means that I, as a web application user, can traverse directories and actually load files from directories that I shouldn't be able to. And the way this works is through URL manipulation. I'm going to manipulate this URL right here. And if you see, it's http://mydomain.com/?value. Now, generally this would be filled in by the web application itself with something like, I don't know, "baked apple" or something, whatever that value might be, because that's information you put in within the web application.

1:08You submitted some information or something or clicked buttons. And it autofilled this in. But what if I was to instead of put that in there, I put something else, such as the path to a file, like, "../"? Now, ../ means If I have a directory structure and I'm sitting right here, if I do a ../, it means go up one directory or go back one directory. So I would go to this one. And if I did another ../, I would go to this one. And the idea is when I use dot dot slashes, I'm trying to get back to the root of the file system.

1:43And that way, I can go up from there because I know the file structure of that system because it's standardized. So I could do a ../ again. I could put a couple of these in to make sure I get back to root. And then I can put in etc/passwd on a Linux host. And if I hit Enter at that point, it may-- we'll put it this way, if the directory traversal vulnerability exists, it will show me the contents of the etc/passwd file. Now, this doesn't contain the passwords to the system.

2:16But it does contain a list of users and some information about their local profile. So I could get a list of all the users on that host. But I could do other things. I could probably load other files, not just this one. I would want to look for, maybe, Apache config files or look for other types of config files. Maybe I'd even want to try to load something like a bash history file from a user, which contains all of the commands that they've run recently in their command prompt and bash.

2:55Now, the downside to this attack is you do have to know where the files exist within the file system. You can't do, like, an LS to list all the files out, or in Windows, a DIR to list the files. You have to know that they exist and where they're at. So that's why we look for known values, like, the etc/passwd or config files. Ooh, we also definitely look for log files as well because log files contain lots of information. And this is a directory traversal vulnerability.

3:26Next up is a local file inclusion vulnerability, which is similar to directory traversal because when I tell you what it does, you're going to say, well, that's the same thing as directory traversal. Well, not exactly because, again, if I put in a ../../, and I put some of these in, and I load the etc/passwd file, and it works, and I have this local file inclusion, well, I just did that in the directory traversal. The difference is, with an LFI, it actually executes the code that's in this file, if there were any, because a directory traversal does not do that.

4:07So the big key difference here is the ability to run code, because if I loaded a script-- I went, like, ../../, and I put a script .sh, which is a bash script, and I ran that, the LFI would actually run the script, whereas a directory traversal would not run this script. It would probably show me the contents of the file, but it wouldn't actually run it as a script. But 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. We don't get to run commands, like, LS or DIR or change directory or anything like that. We have to tell it a single file. But where does this come in handy? Here's where it comes in handy. Oftentimes, we can find ways through file uploads within an application where we can upload a file to this server. Well, if we can do that, then we can use the LFI to reference the file we uploaded.

5:12And one of the types of files we can upload is called a web shell. And this is a web page that has tools built for us as pentesters, tools like, run commands so that we can run an additional command. We can run these LS and DIR and CD and tools to download files. So we can exfiltrate data from that server. And there's lots of different things we can do with web shells. And by default, in Kali Linux that we use for pentesting, web shells are located in /USR/share/webshells.

5:56And under that directory, you're going to see other directories, like, php and other coding languages because web shells come in different languages. So that is where we could use web shells and local file inclusion to really own a box, because of the vulnerabilities. Then we have remote file inclusion. If you thought local file inclusion was cool, wait till you get a load of this thing. Now, here, instead of a value of a local file, like, ../../, we wouldn't do that.

6:28What we would do is put a URL in here and reference a file on another server. So we put http:slash,slash 192.168.1.103 slash webshell.txt. And what would happen is the system would actually go to that file, read that information, and run it against the web application server. Now, this could be a web shell, like I said there.

7:00Or it could be an exploit for a known vulnerability. Or it could be a script that gets me a shell on the target host that's running the web application, because the fact is, I own this server. This one right here, this 192.168 that's going to be my attacker box or a server I own. So I can put whatever I want to on there. I just tell this host via this remote file inclusion, go to my server, get that file, and run the thing already.

7:35So that is super dangerous because I can do pretty much anything I want to, encoding, and attack this host and do all kinds of things. That's why remote file inclusions are even more scary than the LFIs and the directory traversal. So these have been some great vulnerabilities to talk with you about as far as web applications. And we're going to be exploiting these in some upcoming videos. So stay with us. I hope this has been informative for you, and I'd like to thank you for viewing.

0:06We're wrapping up our web application vulnerabilities by going through some various attacks, including clickjacking and brute force. So here we go. So we're starting with clickjacking. That's a cool name. So what is clickjacking? Well, when you visit a web page, there's lots of pictures and things on the page. There's images. There's mountain peaks. The sun's shining in it. And there's other things, too.

0:36There are articles with information. You know, there's all kinds of things-- and titles-- on these web pages. Well, clickjacking is when an attacker uses a transparent field on a website. And so basically, they put this field over something that you're going to click on. But this transparent field contains some code. So when you click on it, you're not actually clicking on the underlying link. You're not at all. You're clicking on the data or the scripting in the transparent field that's there.

1:09So you're kind of being hijacked at that point. And that is known as clickjacking. And it relies on the transparent field, and it actually runs in iframes. And in order to prevent this, you can set your x-frame options to use a Deny response header, which will prevent the iframes from being used on the page. And that is clickjacking. Then we have brute force attacks. This guy looks like he could brute force into several things.

1:40So brute force attack is when we have a website or web application, and somewhere in it-- usually, this is brute forcing credentials. So you've got username and password here. And so what a brute force attack does is it uses a tool or script to run through and use, generally, a given username, like admin. And then it will use a password file, which is just a file that contains a whole bunch of possible passwords, maybe thousands upon thousands of them.

2:16And your brute force tool is going to go out and try all of these different passwords with the username that you supply. Now you can do a brute force where you use a file for both the username and the password. So it'll go through and test all the different usernames and password combinations to try to brute force your way into this web application or website. How do we prevent this? Well, we have to implement account lockout, so that an account will lock out after so many failed log attempts.

2:49Like three or four failed login attempts, and it'll lock for 15 minutes, and then auto-unlock. So an account lockout is how we can prevent that from happening. The other thing is we want to make sure we have appropriate logging that's happening in our applications and on our servers, and that we're analyzing those logs, so we can see these attacks happening. And then we can block those types of attacks. Then we have session Hijacking and this is actually pretty interesting.

3:20Session hijacking is when we try to steal a cookie, which contains a session ID. This session ID contains authentication information that we can use to impersonate the user. So if I was just able to steal a cookie-- and that could come from the web app server itself, or could come from the user's browser window, either one-- then I could impersonate that user, and login to whatever that web application or website is.

3:59And I get hijack that session and gain access to it. One way to steal cookies is to do it via cross-site scripting vulnerabilities. And we're going to look at how to do that in an upcoming video, which is pretty darn interesting. And we're wrapping up with redirects. Redirects-- as you can see in this URL here, we got mybank.com/example.php? And then we see another URL, and this is a redirect. This is often used in social engineering attacks.

4:31So the idea is if I was to-- as a bad guy, I'm sending a social engineering attack. Let's say a phishing email. And it contains this URL. Well, I'm probably going to use something called obfuscation in this URL piece that's circled right here so that this looks different. It doesn't actually look like a URL. Obfuscation can encode this information here. A popular type is called base64 encoding. And that way, it looks like there's a string of random characters and not a URL.

5:02But if I was to insert this into here, and send it to my happy-go-lucky target here, and this happy-go-lucky target clicks on that link and goes to it, well, they're actually going to the real mybank.com. But they're then being redirected to this URL. And so when they hit that site, that's something they recognize. And if you look at just this URL, and that is the standard URL for your bank, then it's hard to detect a phishing attack.

5:34It's hard to detect that social engineering. So how do we prevent this? Well, that actually goes back to whoever owns this website. That's the person that has to do this. And they do this by not allowing redirects and forwards in the web configs of their website. So if you were to hit their site, and it sees this redirect, it would not allow it to happen. But some sites have to allow it to happen for the way they work. Well, in that case, oftentimes, you'll see a warning page that says, "You are leaving."

6:12And then that way, you know you're being redirected to somewhere else. And that is redirect. And that wraps up these vulnerabilities and attacks. I hope this has been informative for you, and I'd like to thank you for viewing.