Welcome to Cross Site Scripting defined. Today, we'll learn about the various forms
of cross site scripting, also known as XSS. Cross site scripting is a
significant issue across all web programming technologies. When you are
creating a website you may want to think about how to prevent XSS.
It's important to understand so that you can guard against it and even test your
site for vulnerabilities. An estimated 90% of all websites have at least one
vulnerability, and of these, 70% are XSS related. Websites are vulnerable anywhere
script can be injected. For example search fields, cookies, forums or even
feedback forms and comment sections. One way to protect your site might be to
eliminate the ability to make hyperlinks, use divs, and pop-ups
A website is vulnerable if it allows a user to input text that is immediately
visible on the page.
For example, the search result or a custom error message.
The goal of XSS is to insert a malicious script into a site
and get the page to render it.
Typically this is JavaScript or HTML code.
Let's look at an example.
A hacker will find a vulnerable site and test it by
typing something into the URL and seeing if it is passed into the page.
You can use the message command and see if you want the text to be prominent,
H1 is a great place to put it.
But what if the hacker wants a wider distribution?
He might decide to put the code into an email
and distribute it to a number of people
When people clicked on the link in the email, the code would be activated
and pass the payload into the webpage.
Anything that is server-side code has
the potential to be written in a way that is XSS.
This is because the website
doesn't know what is content and what is code.
Hackers get crafty and will write a
URL to pass in funny messages into a web page.
They may get really clever and
write code to pass in a link that might say, "Click here and win a prize!"
When, in fact, there is no prize.
What actually happens is that the user is passed through
to an evil website.
Another place XSS might occur is on a blog.
A hacker might use the comment box to inject
harmful code.
A static web page, say that ends in HTML, can't be cross-site scripted
In order to understand today's terminology,
it helps to understand the history.
Before 2012, XSS was described as either persistent or non-persistent.
So what is a persistent or stored XSS attack?
A stored attack is when injurious code is injected into
an existing and trusted website. It's called persistent or stored because the codes
then lives there, and continues to execute for the life of the website.
It will persist until it's discovered or eliminated.
Then what is a non-persistent attack?
Also called a reflected XSS attack.
In this type of attack, the malicious script is
delivered as part of a URL. Usually, it is part of what seems to be a
genuine link in an email.
This reflective type of attack is the most common attack today.
The link might appear to be a genuine domain, and chances are it is, but
it also has a complex URL that contains parameters. This makes it a great place
to hide a call to inject script.
There are two categories of XSS based on where the untrusted data is used.
Server-side XSS and client-side XSS.
Let's take a closer look at these.
Server-side XSS occurs when an untrusted user supplies data that is included in
an HTML response generated by a server.
This data might come from a single
request or from a stored location. This means it could be either persistent or
non-persistent as both fall under the category of server-side XSS.
How about client-side XSS? Well, as you can imagine, client-side XSS comes
from untrusted user-supplied data. When the untrusted data is used to update the
DOM with an unsafe JavaScript call, the DOM allows objects on the webpage to
be manipulated. This means they can be deleted, added, or changed.
If the data being supplied is malicious, it's considered to
be an attack.
This also means that client-side XSS can be both reflected and
stored at the same time. So, DOM based attacks are simply a subset of
client-side XSS.
The focus is on the source of the data.
Here's a chart that should help with understanding the relationship between
current categories of XSS and historically used terms of XSS attacks.
Congratulations, you have just completed Cross Site Scripting Defined.