CompTIA CYSA+ CS0-002 – Mitigate Web Application Vulnerabilities and Attacks part 1

1. Directory Traversal (OBJ 1.7)

Directory traversal. In this lesson we’re going to talk about directory traversal attacks and the vulnerabilities associated with them. Now when we talk about a directory traversal attack, this is a type of injection attack and injection attacks occur when the attacker inserts malicious code through an application interface. Now the one we’re going to talk about specifically here and focus on is directory transversal. Now a directory traversal is a type of injection attack and any kind of injection attack really focuses on the ability for the attacker to insert malicious code through an application interface. Now when we talk about a directory traversal, we’re talking about an application attack that allows access to commands and files and directories that may or may not be connected to the web document root directory.

Now if you’re running a web server, you’re running this on Windows or Mac or Linux or Unix or some kind of operating system and there’s going to be a folder in there that is called the web document root. Essentially that folder is where when you go to Deontrain. com, it goes to find those files. Now that isn’t the root of your hard drive, it’s just the root of that directory. But there’s many folders above that. And so if I went to something like Deon training, etcshadow. That would try to go and find that shadow file. Now that shadow file isn’t inside the web root though. Instead it’s located on some other file off of the directory. And so what we’re doing here with that is doing a directory traversal. Now let me show you what this looks like graphically. Essentially we have something that looks like this. The root is the actual root of your hard drive.

So my server happens to be using Linux and because we’re using Linux, we’re going to be using that slash. Now that’s the root. Underneath that I have two folders. I have slash etc and slash home. Now if I go underneath the home directory I have slash programs and if I go under that I have www root and under that, that’s where my web pages are stored. So the www root, that is my web root directory for those documents. So when somebody tries to go to Deontraining comtcshadow, what are they trying to do? Well, if we start with Deontraining. com, that’s going to load index HTML or index PHP from the web pages. That’s, that blue thing in the bottom right corner. Now when I go dot slash, I go up into the folder above it and then dot, dot, slash goes again up into the folder above it, goes up into the folder above it, goes up into the root directory.

Now and then I go slash etc down into the etc folder and then slash shadow, I’m going to try to read that shadow file. That’s what they’re doing here. That’s what a directory traversal is. And so if we can read those files or execute those files by doing this we can do that from a URL by typing into a browser and remotely attack that system. So we don’t want this to happen right now when we look at these, you’re going to see a lot of these dot dot slashes or dot dot backslashes. Now in this case it’s dot dot slash, because Unix systems like Linux and Mac, they use slash if you’re using a Windows system, so you’re using IIS as your web server, it’s going to use backslash because on a Windows system you have your C drive C, and so you’re going to be using backslash.

But a lot of times Windows is configured to accept either way, the forward slash or the backslash, and it will accept both. Now what we want to do with these directory transversals is prevent them from happening. So how can we do that? Now the problem with these directory traversals, like I said, is that they can be used to access any file on a system if they have the right permissions. So if I configure my server correctly, you’re not going to have access as a web user to read my shadow file or my password file, but if I didn’t have it correctly, you could access those and read those right from your browser. And so we want to be able to prevent this from happening. Now one thing I want to warn you about, you’re not always just going to see the dot slash. Now that is the most common way to see it, especially on the exam to identify a directory traversal.

But remember we talked about encoding all the way back earlier in the course. Well people can use encoding against you as well. Attackers can use encoding to hide their directory traversal attempts. So instead of using, they might use percent to e, percent to e, percent to f, and that would be so keep that in mind as well. Now another vulnerability we have to talk about when we talk about directory traversals is file inclusion. File inclusion is when a web application vulnerability is being exploited that allows an attacker to either download a file from an arbitrary location on the host file system by using that directory traversal or upload an executable or script file to open a back door. Now this will come in two different flavors. We have remote file inclusions and local file inclusions.

When we talk about a remote file inclusion, this occurs when an attacker tries to execute a script to inject a remote file into the web app or the website. So if I use something like httpsdentrain. Comlogin PHP, that part is fine, then I have a question mark user equals this is passing the parameter of which user I want to log in as. Now what user am I going to log into? Am I going to log in as Jason? No, we’re going to log in as http malware bad malicious PHP. So what we’re doing is we’re passing this parameter and when our system executes and tries to find that parameter to load it into our database, instead we’re going to load in this malicious script. So this is the idea of a remote file inclusion. We’re including this remote file malicious PHP from this other website into my web server using this type of command.

Now another one you can use is what’s called local file inclusion. Now local file inclusions are where an attacker tries to add a file to the web app or website that already exists on the hosting server. So let’s say on my website we might allow you to upload something like a picture or a PDF or other files as part of our community forum. Well then you could reference that file because it’s already sitting on my server. So in this case you would do something like httpsdontraining, comloggin PHP, question mark, user equals. And now here you see this directory traversal windowstemthreetwo CMD exe. Now what are they trying to do? This is assuming that I have a Windows server and they’re trying to go up two directories into the Windows directory, down into system 32 and run the command shell.

This way they can run any program they want that executes in Dos or Windows. Now what is that percent zero at the end? Well, that’s a common tactic that’s used to insert a null character at the end of your URL. That percent zero in URL encoding is essentially a null character. And so this is being used to request to bypass the security mechanisms that would normally add a dot PHP to the end of the request and instead allow us to use that exe extension. Now for the exam, let me give you a couple of quick tips. Anytime you see something with dot slash, I want you to think directory traversal, this is what the answer is most likely going to be. Now the reason for this is because on the exam they’re going to bring up the idea of directory traversal a lot. Now you might also get some questions about local file inclusions. And if that’s the case, that is a type of directory traversal.

Now if you get a question like this on the exam, you’re not going to have answer choices A-B-C and D, where A is directory traversal and B is local file inclusion. They won’t do that to you. Instead you’re going to have on this question directory traversal. On another one you might have local file inclusion. So if you see, it’s one of those two things. Now when you’re on the exam you’re going to be asked to look at logs and things like proxy servers. And as you’re looking through the proxy server logs, you’re going to see these different URLs inside those logs. And as you look at them, anytime you see that, I want you to remember that is directory traversal and that’ll be the right answer for you on the exam.

2. Cross-site Scripting (OBJ 1.7

Crosssite scripting. In this lesson, we are going to talk about crosssite scripting. Now crosssite scripting is also known as XSS. Now crosssite scripting is a malicious script that’s hosted on the attacker’s site or coded in a link that’s injected onto a trusted site, designed to compromise clients that are browsing that trusted site, thereby circumventing the browser security model of trusted zones. Essentially, we’re trying to get you to click on something or run some kind of script that your system doesn’t want to do. We’re trying to bypass your security. Now, when we talk about cross site scripting, I want you to remember cross site scripting is a powerful input validation exploit. So what does that mean? It means to protect yourself from this, you need to do input validation.

If you’re not doing proper input validation, you are going to fall victim to a cross site scripting attack. Now, how does this really work in the real world? Well, there’s really four steps to a cross site scripting attack. Now, in its most basic form, the first step of a cross site scripting attack is for the attacker to identify input validation vulnerabilities within a trusted website. So let’s say they find my website and they find out that when I’m taking input into my username and password for you to log in, I’m not validating that data. That would make it a good candidate for cross site scripting. Then they go into step two, which is where the attacker is going to craft a URL to perform code injection against that trusted website.

Now, while they’re in this step number two, they’re also going to try to get that link to somebody, right? And so they might do this by posting it on a trusted website or embedding it into an email message or into a forum post or something like that. Any way they can get this crafted URL into somebody’s hands where they can click on it when they’re on a trusted website is a good deal for them. Then they go into step three. This is where the trusted site is going to return a page containing the malicious code injected. So the user has clicked the link and the trusted site is going to execute its code inside of its site. But we’ve injected this other code through this link, so now it’s going to embed that malicious code inside and present that to the user.

Now the user thinks it’s trusted because it’s coming from a trusted site. And so on number four, we see the malicious code is going to run in the client’s browser. Now when this happens, it’s going to run with the permission level of the trusted site because it thinks this came from the trusted site. And that’s why we call this cross site scripting, because if I’m going to Facebook and somebody has injected code into it, it’s crossing from their site into Facebook and then from Facebook to me, and I’m trusting it because I trusted Facebook. That’s the idea here. Now, the malicious code here could be used to do lots of different things. It might deface the trusted site by adding some kind of extra HTML code. It could steal data from the user by taking their cookies.

It could try to intercept communications that are being entered into a form. Or it might try to even install malware on your system. There are lots of things we can use cross site scripting for as an attacker. And so we want to make sure we’re trying to prevent it. Now again, the reason why cross site scripting is so dangerous here is because it breaks the browser security model. Because browsers assume that scripting was safe. That’s how they were designed. They were designed to assume that when they’re talking to a trusted site and that trusted site gives them scripts. That was something they were supposed to run because that is how websites are designed. If you go to my website, there are scripts that have to run, otherwise you can’t get your quizzes.

That’s the idea here. And so this is one of the reasons why cross site scripting is such a dangerous thing for us. Now, let me show you what an example of cross site script scripting might look like. We talked about crafting these URLs. Well, let’s say I wanted to do one and I did it on my own site, https deontrain Comsearch question mark q equals and then you see bracket script percent 20 type equals application slash JavaScript alert XSS script. Now, what is this saying? Well, we’re going to my site, the trusted site, and we’re going to search something. Now normally we would have a search query here, that’s what Q equals. And we would type in a word like maybe you’re trying to search for CompTIA voucher. So you would type in CompTIA and then you would search based on the keyword.

CompTIA that was passed to my database. Well, in this case instead we are going to run this script. This is a basic JavaScript. It’s going to cause an alert to pop up and the alert that’s going to pop up is just going to say XSS. This is something we use to test if your site is vulnerable to cross site scripting. But it still shows the point. We’re taking code that shouldn’t be trusted and running it through your site. And this is how you can do this kind of thing with cross site scripting. Now, this example that I just showed you is what we call a reflected or nonpersistent cross site scripting attack. The reason it’s called that is because it only happens once when you click on that link or you load it into your browser and hit enter. It happens one time and it stops. It’s not persistent.

This is why it’s called a non persistent cross site scripting attack, also known as reflected attack. Now, in addition to that, we have other types. We have ones like persistent cross site scripting. Now this is an attack that inserts code into the back end database that’s used by the trusted site. Now the benefit of doing this is that you don’t have to wait for somebody to actually click on a link because it’s already embedded into that database. And so with a persistent cross site scripting attack, it sits there always because it’s already been injected. We don’t have to get them to click my particular link, it’s already there. Anytime they load that thing from the database, they’re going to load in that cross site script. Now when we talk about these different cross site scripting I mentioned, there was reflected and non persistent and persistent.

These attacks occur as what are known as server size scripting attacks because I’m having the server execute this code and present it to your browser to trust. Now there’s another type of cross site scripting attack known as a Dom cross site scripting attack, which is document object model cross site scripting. Now when we talk about this, this is a client side attack. This is an attack that exploits the client’s web browser using client side scripts to modify the content and layout of the web page. When we talk about the document object model, the Dom, that is how we display things in the client browser. And you can change that and modify it if you have the right codes. Now let me give you an example of this. Here’s a website URL httpsdontraining comindex HTML hashtag default equals script alertdocument, cookie script.

Now at first glance, this looks a lot like the other one we had. We had some kind of a script and some kind of an alert happening. But the difference here is the payload itself. What we’re doing here is we are alerting on document cookie. The document there is the document object model, the Dom, and in this case, I’m trying to access the cookies that are stored inside of that web browser. This is the idea of what’s happening here. This payload is going to happen on the client side. When the client sees this, it goes, oh, document cookie, you want to see what my cookies are? And it will display those cookies. That’s the idea here with this Dom variable of document cookie. Now there’s other ones out there with document, other things like document write, document location and other things like that.

Now again, when you’re dealing with a Dom cross site scripting attack, you’re going to be running with the logged in user permissions of that local system. When we talked about the browser models before, based on server side, it only has the browser’s permissions. But now we actually have even more permissions because we can do whatever we want on the local system because we are a user level on that system. Now for the exam, when you see something with script in it, it’s usually going to be a cross site scripting attack. So if you see that bracket script bracket, that’s an idea of a cross site scripting attack. If you see something with JavaScript as part of the URL that was captured within a log, again, this is likely going to be a cross site scripting attack.

Usually you’re not going to be asked to be identified between these three types of attacks between reflected or non persistent, persistent or dom. When you’re talking about cross site scripting attacks, you’re just going to be asked, is this a cross site scripting attack or not? Now, if they want you to identify something as a Dom cross site scripting attack, they won’t give you the option of the other two in that question. Instead, though, if you see something like script alert document, something like in my example, document cookie or document write, that would tell you this has something to do with the Dom, and therefore it is something to do with that document object model, and it’s a Dom cross site scripting attack.