Cross-Site Scripting (XSS)

Video Activity
Join over 3 million cybersecurity professionals advancing their career
Sign up with
Required fields are marked with an *
or

Already have an account? Sign In »

Time
21 hours 43 minutes
Difficulty
Intermediate
CEU/CPE
22
Video Transcription
00:00
>> Cross-site scripting.
00:00
Our learning objectives are to understand
00:00
the basics of cross-site scripting,
00:00
demonstrate how to use the BeEF framework,
00:00
and identify the different types
00:00
of cross-site scripting vulnerabilities.
00:00
I've spoken a lot about server-side attacks,
00:00
attacking FTP servers, attacking
00:00
web servers, attacking SMB.
00:00
These are all server-side attacks.
00:00
Client-side attacks are having to have someone interact,
00:00
like a victim, open up their browser,
00:00
and surf to your website.
00:00
We saw this client-side attack in
00:00
the Wireshark module in the drive-by download.
00:00
That person that did click that link
00:00
and be enticed to go to our website.
00:00
Cross-site scripting is an injection attack.
00:00
We're able to inject
00:00
JavaScript into a web form or into the URL bar itself,
00:00
like SQL injection where we could also write
00:00
SQL queries into things like into the URL bar itself,
00:00
or into a form.
00:00
Cross-site scripting, you can write JavaScript into
00:00
the URL or into a form.
00:00
What makes it dangerous is JavaScript
00:00
allows attackers to do things like steal cookies,
00:00
to redirect victims so they're controlled page.
00:00
You can also inject things like HTML,
00:00
which is not as bad.
00:00
Why? Because HTML is static.
00:00
An HTML injection would just be adding things like
00:00
click this link and that person
00:00
on the page could see click this link.
00:00
But it wouldn't actually execute any script.
00:00
There are three types of cross-site scripting attacks.
00:00
One is reflected, which you send
00:00
somebody a link and it
00:00
executes the JavaScript when they click it.
00:00
The stored, where it's actually written to the server,
00:00
it's actually written to the page,
00:00
reflected is also written to the page when it's executed,
00:00
but stored is on the page.
00:00
You'll see this a lot in web forums where people visit
00:00
the forum and there's stored JavaScript in
00:00
it that may redirect
00:00
the victims of the attacker's control page,
00:00
or there might be a small little image in there
00:00
that actually is redirecting someone's browser or
00:00
having their browser contact
00:00
the attacker's controlled server so
00:00
they can steal cookies and then login as the victim.
00:00
There's also DOM-based.
00:00
DOM-based is hard to understand for a lot of people.
00:00
But it's not written to the server like stored
00:00
or reflected where you can actually see it
00:00
on the source of the page.
00:00
DOM occurs in the document object model,
00:00
which is a hard thing to understand within itself.
00:00
But we'll talk about that a little bit later.
00:00
It's not dealing with the server itself,
00:00
it's dealing with the DOM,
00:00
which is an interface in the browser.
00:00
You won't actually see it written on the page.
00:00
Reflected. Reflected means a victim
00:00
has to click on a link.
00:00
Within that link is malicious JavaScript.
00:00
It's very easy to see that if you
00:00
click a link that has a script tag in it,
00:00
that JavaScript will be executed.
00:00
What an attacker may do is create something like
00:00
a Bitly link or a shortened link that a victim clicks.
00:00
Or they may create a typo-squatted domain.
00:00
What does typo-squatted mean?
00:00
Typo-squatted means if I
00:00
want a typo-squat something like Google,
00:00
instead of Os, I could put
00:00
zeros and the victim would look at that link and say,
00:00
oh, I'm going to Google.
00:00
But in fact, it's Google with
00:00
two zeros as opposed to two Os.
00:00
The victim clicks the link.
00:00
You can have a script in there.
00:00
You can write JavaScript that
00:00
redirects them to your controlled page,
00:00
which could look like a Gmail login,
00:00
and is actually the attacker's
00:00
controlled site and the victim enters
00:00
their credentials and the attacker
00:00
steals their credentials from there.
00:00
You'll see this a lot in Bug Bounty,
00:00
there are so many
00:00
reflected cross-site scripting vulnerabilities.
00:00
I see this a lot with payloads where they'll do
00:00
this script alert1 script
00:00
and they'll show I called it the big scary 1.
00:00
As a client,
00:00
if a pen tester or a Bug Bounty hunter showed this to me,
00:00
I would ask where's the impact.
00:00
You can make a big scary 1 pop up.
00:00
Let me show you what it looks like.
00:00
Wow, there it is.
00:00
Here's the vulnerable site.
00:00
As you can see, it's a vulnerability in MyBB.
00:00
It's a cross-site scripting vulnerability reflected.
00:00
You can see in the URL bar, the script tags.
00:00
Script alert1 and then this URL encoded,
00:00
but that's a forward slash that %2fscript,
00:00
and it's writing an alert box with one in it.
00:00
But we can do better than that.
00:00
I'll show you that with the BeEF framework.
00:00
But if you look at the source of the page,
00:00
you can see that
00:00
that script tag is written into the page itself.
00:00
If you analyze the source,
00:00
if you're having issues with your payload,
00:00
you can mess around and
00:00
look at the source of the page and see
00:00
how it's written into the source of
00:00
the page to modify your payload.
00:00
I've had to do this a lot with submitting
00:00
cross-site scripting vulnerabilities
00:00
for different programs where
00:00
you're trying to get your cross-site scripting
00:00
payload to work and you need
00:00
to focus on the parentheses and where to end.
00:00
You'll see input and then you'll see that I put
00:00
the finishing greater than sign and that closed it.
00:00
Then I added my script tag,
00:00
and that's why that worked as a payload there.
00:00
The BeEF framework,
00:00
this is a lot more impactful than one.
00:00
I'm going to show you the BeEF framework in the demo,
00:00
but how do we use the BeEF framework?
00:00
I had showed you how to set it up earlier.
00:00
But when you start the BeEF framework,
00:00
ensure that your Apache server is running in Kali.
00:00
You need to create a vulnerable web page
00:00
in var dub, dub, dub,
00:00
which is HTML, which is
00:00
your Apache server where that root of that server is.
00:00
You need to create a page,
00:00
you can call whatever you want, with this script in it.
00:00
Script source is your IP address on port 3000/hook.js.
00:00
That's how that BeEF hook works.
00:00
You have to entice the victim
00:00
to click that link that executes
00:00
the JavaScript that redirects
00:00
them to your controlled page.
00:00
You'll change the payload like you saw the big scary 1.
00:00
Instead of big scary 1, this is what I'd put,
00:00
script document.location equals my controlled server
00:00
and the page that I made,
00:00
which is this error.html page,
00:00
which is my malicious page.
00:00
This is what the victim sees.
00:00
Instead of the big scary 1, they get redirected to
00:00
my page and they see
00:00
the application has encountered an error.
00:00
Please try again. That's all that they see.
00:00
But behind the surface and the source of the page,
00:00
you can see that script tag
00:00
with a source being that BeEF hook.
00:00
You can see in BeEF, we've hooked their browser.
00:00
Now let's talk about stored cross-site scripting.
00:00
Again, this is going to be written to the server,
00:00
it's going to be written to things like forums,
00:00
where everyone that visits that forum,
00:00
that JavaScript payload is
00:00
executed and you can redirect victims,
00:00
you can steal their cookies.
00:00
You'll see this a lot in CTFs, capture the flags.
00:00
Now again, think about this
00:00
from the lab maker's perspective.
00:00
They need to script victims.
00:00
They need to script people that go to
00:00
that page and you can see all their cookies.
00:00
It's a lot harder as
00:00
a lab maker to have
00:00
to write a script where you script victims.
00:00
I don't think anyone's going to be sitting there.
00:00
I'm not giving you any hints or anything like that,
00:00
but think about it.
00:00
For PWK or OSCP again, I'm not giving you any hints,
00:00
but they have to script a victim,
00:00
go into that page. Could they do that?
00:00
Sure. It's extra work for them.
00:00
But again, that's why this is a client-side attack.
00:00
This is where you can steal cookies
00:00
from actually legitimate victims
00:00
that visit the page and you can log in as the admin.
00:00
You're looking for the admin user,
00:00
you're looking for the admin user's
00:00
cookies because then you
00:00
can add that cookie to your browser
00:00
and then become the admin.
00:00
DOM-based. I talked about this before.
00:00
It occurs in the document object model,
00:00
and it's not written into the page.
00:00
Like we looked at the source of the page with reflected.
00:00
With stored, same thing is
00:00
written into the page, with DOM it's not,.
00:00
You're not going to see it in the page.
00:00
I have burp active scanner.
00:00
It's a lot harder to find
00:00
because what does burp active scanner look for?
00:00
It looks for when it
00:00
sends a cross-site scripting payload,
00:00
that it will see it in the source of the page.
00:00
It can't do that with DOM-based because
00:00
it's not written into the page itself.
00:00
It depends on the browser.
00:00
All these depend on the browser though.
00:00
I'd say out of all the browsers,
00:00
testing this use Firefox,
00:00
it's the most forgiving
00:00
for cross-site scripting payloads.
00:00
I'm going to do the summary and then I'm going to jump
00:00
right into the demo for BeEF.
00:00
In summary, we should understand
00:00
the basics of cross-site scripting,
00:00
I'll demonstrate how to use the BeEF framework in
00:00
our demo next,
00:00
and then we can
00:00
identify the different types
00:00
of cross-site scripting vulnerabilities.
Up Next