Cross-site scripting is often abbreviated as XSS.
We don't use the abbreviation CSS,
because we're already using that for Cascading Style Sheets
when working in HTML.
So whenever you see XSS we're really
referring to a cross-site security flaw, at least
originally it was a cross-site security flaw
where a browser allowed you to send information between sites
if you had both of those windows open in your browser.
These days browsers take that security into account
and don't generally allow information
to jump from one browser screen to another.
Now most of the cross-site scripting
is something that's occurring to a single site
or you're coming from an external location
to a single site.
It's often created because of errors
in the development of that website application,
and the users are taking advantage of an inherent trust
that the application has, it's on the web page,
it's giving you some input, it's obviously
allowing you to put information into the application.
And because the developers didn't consider
that you might be putting in JavaScript
or some other type of scripting information,
they're able to have that information replay
to other users which can obviously
create security problems.
One type of cross-site scripting vulnerability
is a non-persistent cross-site scripting attack.
This is one that's also referred to as a reflected attack.
Take for example a web search screen.
You're able to input information and search for things.
But what if you could also put a script into that input box,
and the script would perform a function?
Maybe it took information about a session ID,
it took a user's credentials, it took cookie information,
and it sent those through an email to the bad guy all
because you simply ran a search into a normal search box.
This attack takes place in the user's browser.
You don't need a third person, there
doesn't need to be a server standing by,
this all happens in the browser window.
This executes, and the bad guys are
able to steal this information usually without any knowledge
that it's occurring on the front end.
All of this happens with scripting behind the scenes,
it's mailed off or sent off to the bad guy,
and now they can gain access to information that normally they
would not have access to.
Here's an example of a reflective cross-site scripting
attack.
This is a shopping cart, so you can
see the items that are going to be purchased, the price,
I can even update the chart.
We can see the total values here,
we see how much is going to be charged to my credit card,
we would put in a credit card number,
and then, of course, you have that three or four digit
PIN depending on what credit cards you're using.
But in this case, the developer didn't
think that anyone would be changing anything in this field
except adding pin numbers.
But, of course, we could add, for instance, some JavaScript.
This JavaScript is very simple, it simply puts an alert message
on the screen that says bang.
And we can set up this entire invoice
and have someone else access it.
And when they do, they're going to get a message
on their screen that says bang.
Obviously the bad guy isn't going
to present a message on the screen,
they're going to have this JavaScript steal information
from this user and send it off to the bad guy.
In this example, we were able to execute the JavaScript
because the application developer didn't perform
any type of input checking.
If they had, it would have already identified
that this was not a three-digit access code,
it would have removed it from the application,
and we wouldn't have any JavaScript executing at all.
Another type of cross-site scripting attack
is one that is persistent or it's
a stored cross-site scripting attack.
This is when the bad guys are able to take the JavaScript
and store it so that later on people
could retrieve that message or that file
and be able to run that script whenever they're
retrieving that information.
It's persistent as part of that file
or that message that's on that service,
and anyone who comes across that page
is going to get that script running in their browser.
For something like a stored cross-eyed scripting attack
you don't necessarily have the ability
to target the individual user.
Anyone who comes across that script or the page
where that script is stored will run that particular piece
of JavaScript.
On a social networking site this type of attack
can spread very quickly.
You can store that script as part of a post,
and anyone who reads or shares that post
will then have that cross-site scripting attack run.
That means the more popular a post is, the more
that that attack is going to spread
throughout that social networking site.
Here's how a number of vulnerabilities,
including a cross-site scripting vulnerability,
allow you to hack an automobile.
This was discovered in June 2017 by Aaron Guzman.
He's a security researcher, and he
was looking at Subaru's front-end website that
allows you to customize things on your car.
Whenever you authenticate to the Subaru website,
the user's browser receives a token.
What's interesting about that access token
is that it never expires.
So if anybody ever gains access to that token,
they would effectively gain access to everything
under your account.
This meant that once you had the token
and you were effectively authenticated
into that account, you could do things
like add an email address.
So you could add an email address
to someone else's account if you add that token.
And once you add your email address,
you effectively have full access to control things
about that particular vehicle.
There was also a cross-site scripting vulnerability
on the Subaru website, so theoretically you
could embed some malicious JavaScript,
have the user visit the page for their car,
and have that token sent to the bad guy.
They could collect all the tokens
and effectively have control over everyone's cars.
There are a number of things you can
do to protect yourself against cross-site scripting attacks.
One of the things you can do is to always
make sure you know what you're clicking.
Don't click links that are being received in your inbox,
don't click links that you're getting
across instant messaging or text messaging.
Always know where that link is taking you.
You might want to consider disabling JavaScript,
although disabling JavaScript also
disables a lot of websites.
So although that is a good way to prevent JavaScript
from running, it may also be a good way
to prevent a lot of websites from working.
Make sure that you keep your browsers
and other web-based applications updated on your workstation.
There are a number of browser vulnerabilities
that might allow cross-site scripting,
and by updating your browser you can always
make sure that they are patched to the latest version.
And if you're a developer, make sure you're validating input.
The end user should not be able to store scripts or input
scripts into your application.
And if you can stop it at the application,
then you know the cross-site scripting attack is not
going to work.