cross site scripting
are learning objectives are to understand the basics of cross site scripting,
demonstrate how to use the beef framework and identify the different types of cross site scripting vulnerabilities.
So I've spoken a lot about server side attacks attacking FTP servers attacking web servers
attacking SMB. Uh so these are all server side attacks.
Client side attacks are having to have somewhat interact
like a victim, open up their browser and surf to your website.
We saw this client side attack
in the wire shark module and the drive by download that person had to click that link and be enticed to go to our website.
Cross site scripting is an injection attack. So we're actually allowed to or were able to inject
into a web form or into the RL bar itself. Kind of like sequel injection, where we could also write sequel queries into things like uh like into the U. R. L. Bar itself
or into a form. Cross site scripting. You can write java script into the U. R. L.
to redirect victims to their controlled page.
Um and you can also inject things like html, which is not as bad. Why? Because html is static.
So an html injection would just be
adding things like, you know, click this link
and that person on the page could see a click this link
but it wouldn't actually execute any kind of script.
attacks. One is reflected,
They're stored where it's actually written to the server. It's actually written on the page. Reflect is also written on the page when it's executed,
but stored is on the page. So you'll see this a lot in web forms or forums, I should say,
the Attackers controlled server so they can steal cookies
then login as the victim.
And there's also dom based on base is hard to understand for a lot of people
but it's not written to the server like stored or reflected where you can actually see it on the source of the page.
Dom occurs in the document object model of the page document object model which is
hard thing to understand within itself.
But we'll talk about that a little bit later. So it doesn't it's not it's not dealing with the server itself, it's dealing with
the dom which is an interface in the browser. So you won't you won't actually see it written on the page.
Reflected means a victim has to click on a link.
they may create a type of squatted domain. What type of squatted me? Type of squat? It means if I want a type of squat, something like google instead of those, I could put zeros and the victim would look at that link and say oh I'm going to google but in fact it's google with two zeros as opposed to two owes.
and is actually the Attackers controlled site and the victim enters their credentials and the Attackers steals their credentials from there.
You'll see this a lot in bug bounty. There are so many crosses reflected, cross site scripting vulnerabilities
And I see this a lot with payloads where they'll do this script alert one script
And they'll show the big called the Big Scary one
as a client. If if, if a pen tester or bug bounty hunter showed this to me, I would ask, where's the impact. Okay. You can make a big scary one pop up. Let me show you what it looks like,
So here's the vulnerable site as you can see it's my baby. It's a vulnerability in my BB. It's across a scripting vulnerability reflected
and you can see in the U. R. L. Bar, the script tags, right, script alert one. And then as you oil encoded, but that's a forward slash that percent to f
script and it's writing an alert box with one in it. We can do better than that.
And I'll show you that with the B framework. But if you look at the source of the page, you can see that that script tag is written into the page itself.
So if you analyze the source, if you're having issues with your payload,
um, you can kind of mess around and look at the source of the page and see how it's written into the source of the page to modify your payload. I've had to do this a lot with, you know, submitting cross site scripting
vulnerabilities for different programs where you know, you're trying to get your cross site scripting payload to work and you need to focus on the parentheses and you know where to and you'll see input
and then you'll see that I put the finishing um
greater than sign uh and that closed it and then I added my script tag and that's why that worked as a payload there.
So the brief beef framework,
this is a lot more impactful than one. Okay, I'm gonna show you the B framework in the demo, but how do we use the B framework? I showed you how to set it up earlier.
when you start the beef framework, ensure that your Apache servers running in Cali
you need to create a vulnerable web page in var dub, dub, dub, which is html Which is your where your Apache server where the root of that server is.
And you need to create a page and call whatever you want with this script in it script source equals is your I. P. Address on port 3000
4/4 Hook Js. That's how it hooks that beef hook works.
that redirects them to your controlled page.
so you'll change the payload. Like you saw the big scary one instead of big scary one. This is what I put script document location equals my controlled server and my page that I made which is this air dot html page which is my malicious page.
So this is what the victim sees. So instead of the big scary one they get redirected to my page and they see the application has encountered an error. Please try again, that's all that they see.
But behind the surface and the source of the page,
you can see that script tag with the source being that beef hook and you can see in beef, we hooked the browser.
Now let's talk about story cross site scripting.
So again, this is going to be written to the server, it's going to be written to things like forums
and it comes, you can redirect victims can steal their cookies.
You'll see this a lot in C T F says capture the flags where you know now again, think about this from, from the lab makers perspective,
they need to script victims. They need to script people that go to that page and you can steal their cookies. So it's a lot harder as a lab maker
to have to write a script where you script victims, I don't think anyone's gonna be sitting there. Uh you know, I'm not giving any hints or anything like that, but
think about it for PW K R O S E P. Again, I'm not giving any hints, but
they have to script a victim going to that page, could they do that? Sure, it's extra work for them.
But again, that's why this is a client side attack.
So that this is where you can steal cookies from actually legitimate victims that visit the page and you can log in as like the admin, you know, you're looking for the admin user, you're looking for the admin users cookies because then you can add that cookie to your browser and then become the admin
down based. Okay, I talked about this before it occurs in the document object model and it's not written into the page. Like we looked at the source of the page with reflected with stored uh same thing is written into the page with dom. It's not you're not going to see it in the page. It's a lot harder.
You know, I have burp active scanner, it's a lot harder to find because what is what is burp active scanner look for?
It looks for when it sends a cross site scripting payload that it will see it in the source of the page. It can't do that with Don Bass because it's not written into the page itself.
It depends on the browser. All these depend on the browser though. So I'd say out of all the browsers testing this use Firefox, it's the most forgiving for cross site scripting payloads.
So I'm gonna do the summary and then I'm gonna jump right into the demo for beef.
So in summary, we should understand the basics of cross site scripting. I will demonstrate how to use the B framework in our lab. Or I'm sorry, demo next.
And then we will identify or we can identify the different types of cross site scripting vulnerabilities.