Hey, everyone, welcome back to the course. So in the last module, we talked about security, Miss Configurations
in this month, and we're gonna talk about cross site scripting. Or more commonly, it's known as X s s
so quick pre assessment question here, this type of cross site scripting attack is executed directly in the victim's browser, and basically it doesn't send any information to the server.
All right, so if you answered B, you are correct. So, Dom, ex SS, we'll talk about what that is stored and reflected. Both send
information back to the server, but with Dom access says it does not, and script ex SS is actually made up. Answer.
We're learning objectives here again, we're gonna be talking about the risk rating will go over that. We'll also talk about what cross site scripting is. We'll talk about those different types that I just mentioned a moment ago. We're gonna talk about how to check for it, weighs, mitigated or prevent it, as well as the impact that it may have on the organization.
So we see our rating here. Obviously we know red is bad, and so we see that it's very easy to exploit for an attacker to do cross site scripting, we also see that is pretty prevalent. It's actually the second most prevalent issue on the whole lost top 10 list
and the estimated that is found in about 2/3 of applications
for weaknesses. It's pretty easy to detect so you can use, like automated tools, for example, like birth sweet to detect it. And then, you know, depending on the types of whether it's stored or reflected, there may be significant or just light technical impacts.
So cross site scripting basically what it is, we're not validating the data once when it's vulnerable. The data is not be invalidated, so they use your supply. Data is not being validated, that it's actually legitimate, and that allows an attacker to pass malicious code.
As I mentioned, we got the three different types of cross site scripting, so we've got reflected Stored in Dumb, which stands for document object model.
It's sometimes called type zero cross site scripting as well,
some with reflected crusts and scripting. Basically here there's a single http response is being injected, so there's an example of script right there, and we'll see this in our lab that will go over, eh? So basically, we're gonna in the lab. We're gonna be putting a little pop up on the victim's machine or on the victim's browser
on. So we could see what that kind of looks like. No. With with reflected,
if the victim closest or browser than the attack is done right. And then if they open the browser, go back to that malicious website or the most is you r l? Then we can run the attack again, et cetera, et cetera. That's why reflected isn't considered. I mean, it's, I guess, a risk. But it's not a cz bad as stored process script.
So speaking of bad, we have sorts cross site scripting. So this one, we're actually injecting it into a love files, rejecting the code and getting saved into the database
and what this allows the attacker to do that is to have persistence with on the victim's machine. So the victim, you know, every time they're going, you know, opening their browser, it sze continuously being executed. It's executing the coat. So here's one example of just a little script that would do so Basically taking over these recession
on duh uh, taking over the cookie, corrupting the cookie
and taking over their session.
And then we have DOB cross site scripting her as I mentioned. Document Object model.
This one's actually rooted in the victim's browsers, so it's we had seen in the pre assessment question there. This one doesn't actually send data back to the server, but this one does execute on the victim's machine,
which actually makes it more difficult to detect this particular one simply because if we're only running, scanning and logging on the local machine, we may not be able to pick this up
or the least, and may take us a while to pick it up.
So prevalent as I mentioned, it's 2nd 2nd most prevalent on the wall. Stop 10 and already mentioned about the 2/3 of all applications is where we find it,
how to check. So I mentioned you know, automated tools. I specifically mentioned birth sweet. That's one tool. We use it in penetration testing to test for Web website vulnerabilities. And and one of those things is cross site scripting, along with like sequel injection attacks and stuff that we had covered in previous module
impact. So The biggest impact here is we're allowing for remote code execution. And then also, you know, we could have our session taken over eso as an attacker. We could take over the victim's session. We could steal their credentials, still information. And we could also use it to Donald Mail. Where? Other device. Right. So if you wantto
attack an organization, for example, we knew that
employees at that company always went to a certain Chinese restaurant for lunch. We could attack the Chinese restaurants websites When people went when employees went there to look at menu and that sort of stuff, it would inject this code or, you know, possibly inject malware onto their machines, and then we could compromise the systems.
and want to talk about escaping. What that basically means is that, for example, we've used our little alligator tanks. So if you look on your keyboard above the, uh, comma and the period we've got what I call our little alligator tags. Um,
so and in website in Web development. And those would be like we could use those for 80 Mel tanks, for example. And so what we're doing here with escaping, there's work averting key characters like that. And we're trying to prevent interpretation of those characters who were converting nose into something else.
So that way, we don't execute malicious code. Or at least we reduce our risk of
executing malicious code
escaping on trusted http request and then also a content security policy. So what the contents security policy does is it allows website owners to declare approved origins of the content that brothers should actually be allowed to load. So it kind of led to specify like, Hey, we should load this from this particular source and not these other ones.
So a quick post assessment question here Christian wants to protect his organization against cross site scripting attacks. Eso all the following our steps you could take, except which one of these
It's a few chose answer. See, you are correct. So storing unsanitized user input is not a good practice. We want to make sure we we only store sanitized user input. So again we want to make sure that we're on Lee
user input that we've reviewed, sanitized and made sure that there's nothing malicious in it.
All right, so in this video, we talked briefly about cross site scripting. In the next video, we'll jump into our lab. We'll take a look at reflected cross site scripting
and then, in the next module will talk about insecure D serialization. We'll talk about what that is, as well a serialization, so you can understand the concept better.