Hi, everyone. Welcome to this bonus course on cross-site scripting. Cross-site scripting was not included in the 2021 OWASP Top 10 list, but it has been included in many previous list prior to 2021. It is still a very relevant security risk today, so we wanted to offer this technical discussion on what it is and how it works. The video you're about to watch was recorded as part of the 2017 OWASP Top 10, but it is still a very relevant security risk in discussion today. I hope you enjoy the video. This specific course is going over security risk Number 7, which is cross-site scripting. One interesting thing about cross-site scripting is that it used to be a much higher security risk in previous OWASP Top 10 lists, but this most recent, the 2017 version, it has made its way down at Number 7. We'll talk about a little bit of that. Some of the reasons for that is it's not quite as big of an issue nowadays based on some security things that have been put in place with browsers and header responses and things like that from servers. But nonetheless, it's still on the list, still a risk that you need to be aware of. We'll all dive right in and check out cross-site scripting. What is cross-site scripting? Which first of all, you'll see the cross-site scripting is abbreviated XSS. Of course, the X stands for cross and then the SS is site scripting. Anyway, these are injection attacks where malicious scripts are injected into websites by attackers. Basically, if you have a web application that allows malicious code to run, then you could be vulnerable to a cross-site scripting attack. An attacker is going to use one of these web applications to send malicious code, typically a browser side, scripts like JavaScript to a different end user. What these attackers can do is use the cross-site scripting vulnerability to send these scripts, and then the end user's browser is going to execute the script. Again, if the web application is vulnerable, then it will actually send the script, execute the script on the end user's browser. Then the scripts can do any number of things, like access session tokens, or cookies, or keystroke log, or all stuff. They can even rewrite the actual content of the page itself. Anyway, there are a couple of different types. We'll get into this in a second. Some of the types of cross-site scripting are not quite as dangerous as others. Some are pretty dangerous. It really depends on what the attacker is trying to do with the malicious scripts that he would be sending from this cross-site scripting vulnerability as to the severity of what might happen here. Anyway, but nonetheless, again, it could be bad and so you need to be aware of it. We'll jump into the OWASP literature here like we have done on all of these different security risks. You can see here exploitability gets a three, which means it's easy to exploit, prevalence is a three, it's very widespread, detectability is a three, which means it's really easy to detect if your web application is vulnerable to this or not. Then the impact is a two. You can see down there in that bottom right-hand corner, the impact is moderate for reflected and DOM XSS attacks, but then it's severe for stored XSS. We'll get into all those. As you can see there where the reflected and the DOM_based cross-site scripting is not quite as significant or severe, but the stored cross-site scripting is certainly a problem. Anyway, you can do all the math and run the formulas like we've talked about before on how you calculate the score for this specific security risk, and you run them all together and you get the number, and then you put that in the list, and cross-site scripting lands at Number 7. We'll dive into the different things that it goes after and then these specific different types of cross-site scripting. There are three forms of cross-site scripting. I mentioned them just a second ago. But reflected cross-site is the simplest. It happens when this application or when a vulnerable application receives data in an HTTP request and then immediately includes the data in the response in an unsafe way. If an attacker can use a vulnerable web application. Somehow send a malicious script to that web application and that web application will actually run the script immediately based on the attacker's input. Then essentially what the attacker is doing is it's reflecting this attack off of that vulnerable web application back to the victim that would be accessing the web application. Then the victim gets attacked that way. Anyway, so just think of reflecting as an attacker sends a cross-site script and then the script is immediately responded to it's just used immediately in the response. That's reflected, stored is basically when an application receives data, and then it's going to include the data later in an HTTP response in an unsafe way. This would be imagined just from a general perspective if an attacker were to submit unsafe or malicious code to a vulnerable web application, and then that code essentially sat on the Web application and was waiting for an unsuspecting user to come and access that specific page or that specific post or whatever it is. Then when that unsuspecting user accessed that particular post or that page or whatever, then the script would run and do whatever it is intending to do. Again, the stored or persistent happens in a later HTTP response by the web application, so it's not going to be an immediate thing. Then finally, the Document Object Model, the DOM. This is where you're building out your HTML, your web page, you use this thing called the Document Object Model, the DOM. A DOM cross-site scripting attack happens when the application contains client-side JavaScript. This is where your browser has JavaScript and it's going to process that from an untrusted source in an unsafe way. This typically is writing data back to the document object model. If an attacker can somehow slip in some malicious script so that the document object model, the DOM itself, is written in an unsafe way or is executed in a way that it's going to find that malicious script and execute that malicious script, then that's a problem and that is the DOM-based cross-site scripting example. Those are the three different forms of cross-site scripting. A few things that cross-site scripting will look to do or will look to target, these attacks are going to target is things like session, stealing your session, maybe take over your account. You can see all the different things here. Multi-factor bypass, DOM replacement, keystroke logging, all that stuff trick you into downloading software. There's any number of things that an attacker will try to do with this, and so it's, I won't say necessarily the sky's the limit, but an attacker can get pretty creative on what they want to do whenever they're executing a cross-site scripting attack. I would say a lot of times it's a session cookie or a session stealing type situation where they're trying to take over the user's session and then masquerade as that user and then they can do all kinds of other things once they have that session cookie or that session ID from the victim. In that case, specifically, this would be the attacker's foot in the door, if you will, where he's trying to steal your session. Then once he steals your session, then he can start doing a whole bunch of other stuff but the way that he steals the session, in this case, would be via a cross-site scripting attack. Anyway, so that's why from the technical impact or the severity of how bad is this really? Then the answer is, well, it depends on what the attacker is trying to do. Looking at this thing specifically, if the attacker is stealing your session ID, obviously that's a big thing, that's a big deal, it's not good. But then the attacker could go on to do a lot of other things with that session ID based on the fact that he executed a successful cross-site script against you. Anyway, that's the idea behind cross-site scripting, where the attacker is using this in order to achieve maybe a larger or some bigger end goal. He's potentially, very likely not going to just stop with cross-site scripting. He's going to keep moving on to his ultimate goal of, whatever, taking all your money or whatever it's going to end up being. Stealing your identity. Anyway, killing your credit score, whatever it is. We'll dive into the actual examples of the three different forms of cross-site scripting. The first is this reflected cross-site scripting. I'll use my little mouse pointer here. You can see that if a user were to access this web application and it's an example.com. Let's say that this web application allows you to post a status message, and here it's going to say Hello World. Right here in the URL, if this were the HTTP request to this vulnerable web application, then the user's screen is going to land here at example.com, and it's going to say Hello World right there on your screen. It's going to actually execute this message from the URL itself. Well, if this web application allows for that, then what an attacker could do, is say, hey, let me come in here and say instead of message equals Hello World, let's say message equals some malicious code script. Then if the web application is going to actually execute whatever's here in this part of the URL, then suddenly your browser is not going to say Hello World. It's going to run the code. Sometimes the code may actually show you something here. Sometimes it may not show you anything. It may just run code, and it runs in the background, and you didn't even know it run, but it certainly did run, then the question is, well, what is this malicious code? The answer to that goes back to what I was talking about a second ago, it depends on what the attacker is trying to do. This could be anything from again, some keystroke logging attack, or maybe steal your session ID or whatever, steal your cookies, whatever it is. Typically, what will happen here is that the attacker is going to need to send this URL right here to the victim. While this is the attacker ultimately sending this, is really the victim is the one that's going to click on this link. This gets into some of the discussion of spear phishing. Hey, if you get an email, and it's got some unsuspecting link, then don't click on that link, or don't open that attachment, that file attachment in your email that you don't know what it is, or things like that. Or maybe you're on a web page, and you click on a link, and you didn't realize that the link you clicked on was some malicious link that the attacker was trying to lure you into. Maybe you're on some site that is riddled with malware, and you click on a link and whatever. Very potentially you could click on this, the script could be written in such a way that it's going to give you a message that you expect to see, but it's also going to run a bunch of code in the background as well. There's any number of things that could happen here, but the point is, with reflected cross-site scripting, the attacker has found a web application that's vulnerable and he's used this to say, hey, I'm going to put a script in the URL itself. Then when that URL is executed by that web application, then the web application is going to run that script right away. It's going to instantly reflect that script back to the unsuspecting victim. That is a reflected cross-site scripting example. For a stored or persistent cross-site scripting. This is the one that was a little more dangerous, and I'll use my mouse pointer here again. Let's say you have a social media web application. Goodness, you can think of a million of those out there today, where you can post statuses and post pictures and comment on stuff and all stuff like that. Let's say you have something like that, and let's say this particular one is vulnerable. Then typically what would happen here as a user would say, hey, let me send an HTTP post. This is the HTTP method, and it's going to send it to this /forum/sample post, blah, blah, blah, and it's got all that stuff, and it's coming to this socialsite.com, and my name is John and the post I want to submit is Hello World with an exclamation point. If that's the typical standard action of the site, then what will happen is you'll submit this post, HTTP post, and you'll land on this site and user John has said Hello World. Then that's my latest status update or that's my latest message to this message board or whatever it is. That's the way it's supposed to work. Well, let's say that this thing is vulnerable again. Let's say now you have an attacker that understands that, and instead of name is John, imposed this Hello World. Now, the attacker is going to say, hey, I'm John, but my post is some bad code script. Again, the question is, what is in this bad code, or what is this script doing? The answer is, it depends on what the attacker wants it to do. Let's assume in this example that the attacker is trying to steal your session ID. It's going to steal your session ID, and then it's also going to call back to the attacker's own website, and it's going to copy that session ID, and it's going to post it back to some website that the attacker owns. All of that action is embedded in this, like what is this script right here? The question is, does this social media web application allow this post to include this bad script or not. If it's vulnerable, then the answer is yes, it will allow that script to happen there. What's going to happen is, it's going to have here socialsite.com, again, John. Then there's going to be this bad code, and it's going to steal the cookie and send it back to the attacker's website, just like I was talking about a second ago. The reason that this one is so much more dangerous is, this right here can sit there as a stored value, as a persistent value on this page, so that whenever someone else were to access this page and see John and his status and all that, then this script would automatically run on their browser, and it would steal their cookie, and it would send their cookie back to the attacker. Basically, the attacker is just sitting there, and every time someone accesses this site with this post, with this update, whatever, then the attacker is going to get the session cookie from whatever user accessed this, and very easily this code could run without the user that accessed this site even knowing that it ran at all. To the end user, to the unsuspecting victim, they're just visiting their favorite social website. They're seeing that, there's some guy named John out there that. Maybe there's nothing at all that actually shows up here or maybe it has some other text that's been embedded in the code to make it look like, hey, this is just whatever post. But the truth is that there is code embedded in all of this, and it runs, and it's sending information back to the attacker. Anyway, so that's why this one is a little more dangerous is because it can sit here persistently, and it can affect, frankly, anyone that comes back to that particular site in that particular post in this example. That's why stored is more dangerous than the reflected because the reflected is one user clicking on, say, one link, and it sends stuff back to the attacker whereas stored or persistent is going to be there to affect many users, let's say, are many victims. That's stored or persistent cross-site scripting. The last type of cross-site scripting is the DOM, the Document Object Model cross-site scripting. Let's say you have a website, example.com, and it creates a user dashboard that is unique to whoever it is that's accessing that particular user dashboard. It's going to say, hey, here's the main dashboard for user x kind of thing. The way that actually builds out the text for saying this is the main dashboard for John, let's say, so in this case, here's your user dashboard, HTML, context equals John. Well, the actual document object model itself, let's say here's the code here on the web application. You've got to custom dashboard, that's the title of the page itself. Here's the head, this is the HTML code, let's say, and this is main dashboard for, and then it starts to run this script, and by running this script, it's going to declare this variable named POS, let's say position, and it's going to use the document URL itself. It's going to look at this context equals place. Right up here, contexts equals, in the actual document URL contexts equals, and it's going to use that to put the value into this variable position. Then you're going to write out the document itself. This is writing out the Document Object Model. This is writing out the actual text on the page. This right here is a function document.write, and it's going to ultimately call this variable position. That position is going to be populated with the contents of what was in the characters just passed this context equals part of the document URL. Having said all that, essentially what it would do in this case, is it would say, hey, let me look at the document URL. Let me find where it says contexts equals, and then let me take the text or the characters that are just past that, and I'm going to use those characters to say that that's the main dashboard for, and in this case it's going to say John. Let me just show you what the user's screen would say. You would be here at example.com, and it would say main dashboard for John. Super simple. Well that's all well and good unless, and until, you have an attacker that understands that, hey, there's all this stuff going on and there's this client side JavaScript that's running here. If you have an attacker, an attacker could send a bad URL to an unsuspecting victim. Much like what we talked about before, where it's like maybe you have a spear phishing campaign, or maybe you have whatever form the attacker is going to use to try to get the victim to click on this bad link. But using this exact same code to build out this webpage. In this case, it's still going to look for the document URL that's going to find this context equals, except now contexts equals doesn't equal John anymore. Now it includes this script, this bad function with bad variables, and it's all this evil stuff. Again, you can say, "Hey, what's in this?" The answer is it's whatever the attacker is trying to do here. Again, maybe trying to steal your session ID or whatever it is. Frankly, the answer is, what can you do with a script? The answer to that is, just, basically anything you want. There's almost an infinite number of possibilities here. If the unsuspecting victim were to click on this, then it would build out the page and say, hey, this is the main dashboard for, and then as the browser went to build this out, it would ultimately look for this position variable is it's looking, but ultimately it's going to come up here to this context equal, and it's going to see this, and it's going to run this script right here in the context of building out the page itself. What you'd have is main dashboard for, and then here's the script with the bad function and the bad variable and all that different stuff. Again, does this particularly have to say script bad function, all that stuff. It doesn't inherently have to show that. In fact, frankly, an attacker would probably encode this URL payload in order to make it not so obvious that it contains a script, but nonetheless it would still contain the script. The page itself is being built out with this document object model code that has been supplied with a variable value that is a bad script. Again, if your web application allows that to happen, if your browser allows that to take place, then now you've got problems. That's the DOM cross-site scripting attack. This is where you can say, "Hey, I need to not let my web application run that stuff or accept that type of input." Then also you can try to look and see, hey, will my browser even allow that to run? You can look at your browser side as well. A couple of different things that you could try to do there. With that, I wanted to look at a quick demo on this example of testing page that I have. Let's take a quick look there. You can see here we are at this Hack-it-yourself auction page, we've looked at this and other courses in this OWASP top 10 skills learning path. Anyway, it's auction.com and hack-it-yourself auction. This is just a test page that you can hack around with and do a lot of fun stuff. I have logged in here with my user johnwagnon, and I'm logged in and good to go. I want to show you just a proof of concept on this web application allowing scripts to be used as input and then this will actually execute the script right away. This has been like the reflected cross-site scripting type situation. I can show you what it does. Anyways, I'm going to go up here to sell an item. Then I'm just going to put a couple of things here on maybe like test. Then I've got some code here that I'm going to put in. This is script. Then this alert function is going to just pop up an alert window here on the screen. What it is looking for is document.cookie. This is the actual cookie of the session that I have here. Then I'm going to come down here. Auction starts with, I'll say a dollar and we'll fill out a couple of things. We're in, I'll pick Australia and then zip code. I'm just going to say 12345, whatever. I'm going to accept a check. When I hit "Submit Query" right here, the question is, will this web application as it looks at all of the content that has been posted into this page, will it find this and instead of saying, hey, here is the item description of this thing that I'm trying to sell, will it actually run this script? That's the question. If it does, then this is a vulnerable web application that allows an attacker to then try to trick an unsuspecting victim to maybe come to a page like this where you can get it to run a script and steal a cookie and do all the different things that we talked about a second ago. Let's submit the query right here. Sure enough, there it is right there. The session ID is this whole thing. That's my current session ID. You could steal that as an attacker and then load that up and do any number of things. I said, okay there. That was that little document or the popup alert window. Here's the rest of it. You can see here that the item description itself, it doesn't even show anything. We talked about that previously where it doesn't necessarily have to show anything. By the way, on that script, I did not have to say alert and then document cookie, all that stuff. I could have just stolen it and sent it to my website without you ever even knowing as you submitted this thing. Anyway, so you can see how this web application will actually take the script input and will run it. You can do any number of things. I'm going to show you one other thing back here, we're going to go back to Home then we'll look at one other type of attack. We're back here at the Home page here for this site. I'm logged in again with my username johnwagnon. I'm going to go to this Contact Us link right here. You see these a lot with web pages, whatever hey, contexts is for the question or feedback or whatever it is. I'm going to put test in here as just a title for this thing. But then the actual text of the Contact Us form is going to be this script. This is JavaScript as it turns out. We define a function here. It's called MM and then openBRWindow. This is open like a brand new window thing. This function is looking for the inputs, the URL, the window name, and then different features. In this function we're going to have a window open. It's going to open a new window and it's going to be populated with URL, the window name, and features. When we call this function, then we are calling it and we're giving it the values for the URL is user_menu.php?nick=*. We've looked at this one before. If you remember in previous courses that we've done here in the OWASP Top 10 for this specific web application, the nick is like a parameter that's used for a nickname or the name of the logged in person. We were able to say nick equals asterisk. For my personal login account, it should say nick equals John Wagnon. But here we're saying nick equals asterisk, which means give me every single user that you have in your database. Then the window name, IamTheKing because you know, that's just the attacker saying, "Hey man, I'm the king of this thing. I'm ruling your web application." Then features status is yes. Scrollbars is yes, which means you're going to be able to scroll and then this is 800 by 600 window that's going to open up. The question is again, if I hit "Submit Query", is this web application actually going to run all of this code right here? Is it going to run this script? Or is it going to give me an error or what's going to happen here? Ideally, it would not run this thing, it would say, hey, this is a cross-site scripting attempt, or I'm going to not run this stuff, but here let me submit this, and if, and when I submit the query and it pops up a new window, then that means that this stuff all ran, let me see what goes on here. Boom, there it is, and in fact, you'll notice auction.com. remember the URL that we gave, it was slash user menu dot PHP, Question mark nick equals asterisk. Here's an 800 by 600 window right here, we can scroll on it, remember that part? But most importantly, this is every single user that is registered on this site, and it's got their credit cards and their e-mails and their telephone numbers and addresses and all that, one of which is John, and that's me. If an attacker were able to get a victim to click on this thing, then well, actually in this case an attacker wouldn't need to get a victim to click on, an attacker would just put that code right into the web application, it will be able to pull out all of the data from the web application just by doing this type of manipulation right here, in this specific case, the attacker, wouldn't even need a victim at all, he would just put the code into the vulnerable web application, everything would pop up and there you go, then he's got all your stuff. This is where I was talking about before where an attacker is going to use a cross-site scripting attack in order to get information that he needs for a larger end goal. It's like a means to an end. In this case, the attacker is not going to stop here. I mean, they're not going to say, hey, I've got every name and credit card number and all that that I need, and that's all I wanted and my day is done. No, he's going to say, alright, now I'm going to go to Bob Smith, I'm going to steal his credit card number and I'm going to start charging up a bunch of stuff with that. Or I'm going to send, or do whatever I'm going to do with that credit card number, maybe I'm going to sell that credit card number on the black market, or maybe I'm going to whatever, and then likewise with Fred and John and Mary and Chris and John and all the different people. Anyway, that's that. But again, this is an example of a vulnerable web application that actually allowed that script to run, it's also vulnerable in the sense that it allows some of this parameter tampering and it will actually show you this gets back to some of that broken authentication, it's like, hey, this logged in user, I'm logged in as John. Wagnon. I should not have access to this page right here. Anyways, there's just a few things going on with this web application, but this just shows a cross-site scripting version of what you could do. Anyway, there's a couple of different examples of cross-site scripting at work, and now we'll head back and look at a couple of things on how to know if you're vulnerable, and then some ways that you can protect yourself. Hopefully you enjoyed the little demo time there, we're going to look next at are you vulnerable? Here are the three different types of cross-site scripting reflected, if your application includes or your API frankly, includes unvalidated and an escaped user input as part of the HTML output. This is again, where a web application takes user input and it does not validate it, it doesn't escape it, and then it just uses that as part of the output on the HTML page itself, then that's a problem. You need to not do that. An attack can allow the attacker to execute arbitrary HTML, JavaScript, all that stuff that we just saw. Then, I've mentioned as well, typically the user is going to have to interact with some kind of malicious link in order to get pointed to the attacker controlled page, that's the reflected one, are you vulnerable if you allow that stuff, then you're very likely vulnerable to reflected cross-site scripting attacks. The stored or the persistent cross-site scripting you are vulnerable if you store unsanitized user input, that's going to be used at a later time by users or administrators, that stuff, and again, this one's the higher critical risk because it could just be used over and over again by many different users. But again, this is the unsanitized user input that is viewed at a later time or unsanitized user input, I should say that's going to be used in HTTP responses by the web application, don't do that either, don't use unsanitized user input. Basically don't ever trust your user input, I mean, that's an easy way to look at all this. Then finally the DOM, the Document Object Model, cross-site scripting. Whether it's JavaScript framework, single-page applications, APIs, that kind of stuff, if you include attacker controllable data to a page then you're probably vulnerable to DOM XSS. You ideally would not send attacker controllable data to unsafe JavaScript APIs. I know we looked at an example of this. This is where in an example the DOM was being built out and the attacker was able to use a script in the URL itself; in the document URL, and then as the DOM is being built out it calls back to that, and then it runs that script as part of the building out of the DOM. That's a problem if you allow that stuff to happen. Just keep that in mind on the different types of cross-site scripting. Some things to keep in mind in terms of protecting yourself, there are some really cool frameworks that automatically escape cross-site scripting by design like Ruby on Rails, React JS, there some different ones out there. You can Google them up, but that's one really cool way to do this. Just use a framework that automatically helps you out just by its design, so those are really cool. You need to escape untrusted HTTP request data based on the context and the HTML output. If you have HTTP request data you need to escape that, and then that's going to help out with the reflected and stored vulnerabilities. You can apply the context-sensitive encoding when you modify your document on the client side, and then that'll help out with the DOM cross-site scripting. Another thing you can do from your web application side is you can use response headers. We've talked about these a little bit in other courses, but you can use HTTP response headers that are things like content type and ex-content type if you know the type that you're working with. If these responses aren't intended to contain any HTML or JavaScript, then that's when you can use the content type options so that your browsers don't interpret the responses in the wrong way. Also, you can use the content security policy header to guard against cross-site scripting. Content security policy, it makes it possible for server admins to reduce or eliminate these attack vectors, and it does that by specifying the domain that a browser should consider to be valid sources. If you're going to have some executable script; that thing, then essentially you're telling your browser, hey, these are the valid domains or the valid sources to look at. If you have a content security policy compatible browser, then that browser will only execute scripts loaded in the source files from those allow listed domains and it will ignore all other scripts based on the content security policy that you've got. That's another way that you can attack this from both sides. You as just a user if you don't want to fall victim to a cross-site scripting, you can use a browser that is content security policy compatible which most of the modern ones are. Then from the web application side, you can use these respond headers; these security response headers, for the HTTP responses. Those are a few things you can use. Then I know I've mentioned these before you've got the cheat-sheet right here for the cross-site scripting that the OWASP has. There's this and then there's actually a few other ones that you could go check out. As you go to owasp.org/cheatsheets, then you'll see a whole bunch of these things. There's a bunch of really good just practical application that you can use as you build out your web application things to keep in mind and say, hey, don't do this, do this as you build out your HTML. All the different parts and pieces of your web application, there's just some really good practical advice and the cross-site scripting cheat sheet, so make sure you get out there and check those out. With that, we will wrap up this cross-site scripting course. I hope you've learned a couple of things here in this course. I hope you've enjoyed the content with the demos and all the different things, and I hope that you stay safe and secure against the cross-site scripting attacks that might come your way. We want everyone to be safe and secure out there. Thanks for hanging in there with us today and I hope you have a great day.
