In this lesson,
we're going to discuss Cross-Site Scripting,
also known as XSS.
Now, cross-site scripting is a malicious script
that's hosted on an attackers site,
or coded inside of a link
that's injected into a trusted site,
designed to compromise the client
that is browsing that trusted site.
Now, this allows the attacker
to circumvent the browser security model or trusted zones.
Now, the attacker's goal in using cross-site scripting
is to get you to run some kind of malicious script,
so that your system will process this thing,
and bypass its normal security mechanisms.
Cross-site scripting is a powerful exploit
that relies on your website
not conducting proper input validation.
If you're not doing proper input validation,
you are most likely going to fall victim
to a cross-site scripting attack.
So let's take a look at
how cross-site scripting works in the real world
by looking at the four basic steps
of a cross-site scripting attack.
First, the attacker identifies
an input validation vulnerability
within a trusted website.
For example, if my website doesn't conduct
proper input validation
for the username and password fields used by my students,
that could become a good candidate
for cross-site scripting attacks.
Second, the attacker crafts a URL
to perform the code injection
against that trusted website.
At the same time,
the attacker needs gets somebody
to click on that maliciously encoded URL.
So they might post it to a trusted website,
embed it in an email message using a phishing campaign,
or post it to an online forum.
The goal here is that the attacker
needs to get somebody to click on that encoded URL.
Third, the trusted site will return a page
containing the malicious code injected,
as well as the regular site code.
This occurs once the user clicks the encoded URL,
and the trusted site executes the code that was injected.
At this point, the user is going to be presented
with malicious content,
which they believe is trusted,
because it came from the trusted website
that they were visiting.
Fourth, the malicious code is now run
in the client's browser,
finalizing the cross-site scripting attack.
When this occurs, the code will run the permission level
of the trusted site,
because the system believes the trusted site sent that code,
which technically it did,
because it was injected into the reply
coming from that trusted server to the end user's browser.
This is why we call it a cross-site scripting attack,
because malicious code is actually going to be injected
and served by the trusted site to their users.
Now, for example,
let's say I was scrolling Facebook
and somebody was able to perform
a cross-site scripting attack there,
and they can inject code into my newsfeed.
Now it's going to cross that threat actor site
into the trusted site, in this case Facebook,
and then it's delivered to me,
the end user who's scrolling my newsfeed.
That's how a cross-site scripting attack works.
Now, cross-site scripting attacks
can be used to run malicious code
that perform many different functions.
One attack may focus on defacing the trusted website
by injecting extra HTML code into it.
Another attack might focus on stealing the user's data,
by stealing protected cookies from that user.
Another might try to intercept data or communications
as they're being entered into the web forms.
And yet another might try to install malware
on your client's system.
As you can imagine,
there are lots of different things we can do
with the malicious code being run,
but cross-site scripting is the initial delivery mechanism
that the threat actor is going to use
to get that malicious code to your system,
and have it run by your web browser.
Now, the reason cross-site scripting is so dangerous
is because it breaks the browser's security and trust model
because browsers are going to assume
that scripts it receives from a trusted site
should be safe to run.
Now, this isn't the browser's fault,
it's just because they're designed to run scripts
they receive from trusted sites.
That's how the internet is designed.
After all, if you go to my website,
there are lots of different scripts we're running
in order to provide you with the training videos,
quizzes, and practice exams that you want.
Your browser knows that it can trust my website,
because there's a valid digital certificate,
and you've logged into our site,
and therefore you're a trusted client,
and we're a trusted site.
Without this level of trust,
webpages would be extremely boring,
because no scripts could ever be run or operated.
So let's take a quick look
at what cross-site scripting might look like
if we used it against a vulnerable website.
First, we're going to craft the URL
by adding the script to an otherwise safe URL.
For example, if my site was vulnerable,
we could use a URL like diontraining.com/search?q=
and then you'll see something like,
alert('xss').
Now, what does this really say?
Well, the first part here is simply saying,
we're going to use a trusted website like diontraining.com.
The next part that says, search?q=,
would normally be used for a website
to conduct a search for anything found after the q=,
because that is my query.
For example, maybe you're on my site,
and you're searching for the word CompTIA,
so you would see in the URL, q=comptia,
and that would send the word CompTIA to my server
to be able to search its database for any pages
that have the word CompTIA in it.
Now, because we're attempting
a cross-site scripting attack here,
we're actually going to replace the query
with the script that we want to insert.
In this case, I have a really short piece of JavaScript code
that's going to pop up an alert box that says XSS
when it goes and reaches the server.
Now, if you try to run this code,
it probably won't work on my website,
because my site is already protected
from this type of cross-site scripting attack.
But if you want to attempt these on your own,
you could check out the cross-site scripting game
set up by google at xssgame.appspott.com,
which has six different challenges
where you try to create a cross-site scripting attack
against their servers.
The first one can be completed
using the example I just covered in this lesson.
Now, the example I just showed you
is what's known as a reflected or non-persistent
cross-site scripting attack.
This type of attack only occurs
when it's launched because you're clicking on that link,
or you're entering it into your web browser
and pressing enter.
When it happens, it happens once and then it stops,
because it is considered non-persistent.
Now, there are other
types of cross-site scripting attacks though,
and these can be more dangerous.
For example, a persistent cross-site scripting attack
allows an attacker to insert code into the backend database
used by that trusted website.
By doing this, the attacker doesn't have to wait
for somebody to actually click on a link anymore,
because the malicious code is now embedded
into that website's database.
Anytime a user loads the page,
or content from the database,
they're going to be loading
the persistent cross-site script as well.
Now, both persistent and non-persistent
cross-site scripting attacks
are considered forms of server side scripting attacks,
because it's the server that is executing the scripts
that we're injecting.
Now, there's also a client side attack
known as a DOM cross-site scripting attack.
Now, DOM or D-O-M
is the document object model,
and the document object model cross-site scripting attack
is going to exploit the client's web browser
using client side scripts
to modify the content and layout of the webpage.
The document object model or DOM,
is how things are displayed in the client's browser.
But by injecting scripts into the DOM,
you can actually change this.
Now let me show you a quick example
of a DOM based cross-site scripting attack.
In this simple example,
you can see a URL
of diontraining.com/index.html#default=
alert(document.cookie).
Now, at first glance,
this looks a lot like
the non-persistent cross-site scripting attack
that I showed you earlier,
and both of these do have a short script,
and an alert being issued.
But the big difference with this one
is actually in the payload itself,
because we're using the alert to show the contents
of document.cookie.
Now, when you see the word document here,
this is an indication that we're looking at the DOM,
or the document object model inside of the web browser.
In this example, we're trying to access
the cookies stored inside of the web browser's DOM,
and therefore we're trying to execute this in the browser
and display the contents of those client's cookies.
If the web browser is vulnerable to this,
you're going to then see code go, "Oh, I see this code,
you're asking for document.cookie.
You want to see what my cookies are.
Well, let me show you."
and will display those cookies to the screen
using this alert.
This again, is a simple example,
but there are many more dangerous ones out there
that could be used like document.write,
document.location and other things
that can access and change the DOM environment.
Remember, when you're performing
a DOM cross-site scripting attack,
it's going to be run using the logged in user permissions
for that local system.
So if you're lucky enough as an attacker
to have a system administrator
who executes your DOM cross-site scripting attack,
guess what?
You now have access to that system
as a system administrator too.
Now, for the exam,
let me give you a couple of quick tips.
First, anytime you're looking at a log snippet,
or captured URLs that have the script,
or any kind of JavaScript inside of them,
it's most likely going to be a cross-site scripting attack
that's going to be the right answer for that question.
And second, if you see something
with document. something in it like document.cookie,
or document.write, this should tell you
it's a DOM based cross-site scripting attack
because it's affecting the document object model
of your browser.
If you keep those two tips in mind,
you'll do great on the exam.