In this video, we'll look at ways
that cross-site scripting can be used
to take advantage of vulnerabilities
with an application.
You often see cross-site scripting abbreviated
as XSS instead of CSS, which you might expect
from cross-site scripting.
However, the CSS abbreviation has already
been used by cascading style sheets.
So we use XSS to specify cross-site scripting.
We call this cross-site scripting
because we're able to take information from one site
and share that information with someone else.
This is caused by vulnerabilities
that might exist within a browser, which
is why it's another good reason to always have your browser
updated to the latest version.
Although the browser is part of the equation,
the software that's running inside of the browser
is the other part of this equation.
If someone was to write code that would not
allow a cross-site scripting, it could
be stopped within the code of the application
itself even if the browser was vulnerable.
This is a relatively complex vulnerability
that's difficult to identify unless you already
have knowledge of the code that's being used.
So if somebody is developing a web based application,
they would need to look in their code
to avoid any type of cross-site scripting vulnerability.
If you think of this in very broad terms,
you could say that cross-site scripting is malware
that takes advantage of vulnerabilities with JavaScript
inside of your browser.
And although you may think that disabling JavaScript
in a browser would resolve this issue,
every website you visit has some amount
of JavaScript running that's important for the operation
of that site.
So simply disabling JavaScript is probably
not the most effective way to deal with this issue.
The first step in taking advantage
of a cross-site scripting vulnerability
is to run some type of script inside of a user's browser.
This might be a search box or some other type of input
in a web based application.
This exploit commonly takes the form
of an email that is sent from the attacker to the user.
The user clicks a link inside of that email that
then runs a script that takes private information
such as user credentials, session
ID, or other sensitive details, and it sends that information
to the attacker.
This script executes in a browser
as if it came directly from a web server.
But in reality, the attacker has added their own JavaScript
into this particular link.
And once this session ID or user credentials
have been sent to the attacker, they
would now have access to the account
that you were using on that website.
Let's perform a cross-site scripting attack.
In this case, we're going to perform it
against an application that is vulnerable on a website that
provides a checkout process through a shopping cart.
You can see that I have a number of items in the shopping cart.
There is a total amount of money that will
be charged to my credit card.
We've also got credit card numbers and input
for the access codes and then a purchase button.
Since we're logged in to this website,
an attacker could take advantage of that trust.
If the attacker just had the session ID,
they would be able to put that session ID on their machine
and effectively have the same login
session from their browser.
Let's add some JavaScript to this page
to see how an attacker might be able to retrieve that session
ID.
I have some JavaScript that I've created here.
You can see it does a script alert.
This one shows your session information
and displays the session ID on the screen.
Obviously, the attacker would not
be displaying this information on the screen.
Instead behind the scenes, it will
be sending that information to the attacker
through other means.
The end user would have no idea that the session ID was even
collected by the attacker.
So let's highlight this and let's copy it.
Let's now add that script to the end of the credit card number.
And I'm going to click the purchase link.
And now you can see that your session ID
has been written to the screen.
This is the information that would go to the attacker.
And once the attacker has the session ID,
they can access your account from their browser.
Now let's perform another cross-site scripting attack.
This one is called a persistent or stored cross-site scripting
attack.
In this case, we don't have to worry about an attacker
sending an email or having the user click something that's
in their browser.
Instead, we're going to put the malicious code
on a centralized server such as a social media site.
The attacker could create a comment
on the social networking site, and inside of that comment,
place their malicious code.
Anyone who visits that page or reads through those comments
would effectively also be running that JavaScript
in their browser.
An email containing a link is very directed at an individual.
But something like a stored cross-site scripting attack
on a social networking site is one
that affects anyone who visits that page.
This is something that could obviously spread very quickly,
especially if there are many users
to that site and many people viewing
the page that has that comment.
There have even been cases where cross-site scripting attack has
been made against a car.
In 2017, a security researcher named
Aaron Guzman was able to log in to the web based
front end of his Subaru.
From that web based front end, you're
able to perform a number of functions in the car itself.
Once you log in, each user gets a session ID
or a token that allows them access to their account.
The first problem that Aaron found
is that this token never expired.
So once you logged in, your account
was always available with that session ID.
Even worse, the session ID information
was not properly validated.
So you could use anybody's email that
had an account on the Subaru website include the token
that you generated for your account.
This effectively allowed Aaron full access
to other people's vehicles.
Even if you didn't own a Subaru, you
could send an email with a cross-site scripting attack
inside of it, have the user's token sent to you,
and now you could use that token for anyone
on the Subaru website.
This was obviously a significant vulnerability
and Subaru was able to correct their software
to avoid this problem in the future.
There are a number of different ways
to mitigate a cross-site scripting attack.
One is a rule that you should really
apply to anything which is never click information that's
being provided to you inside of an email message.
Since the details of what you're clicking
are effectively hidden from you, and in some cases,
very difficult to know what you're clicking on,
the best practice is to never click any of those links.
As we mentioned earlier, you could simply
disable all of the JavaScript inside of your browser.
This will probably break most of the sites
that you normally visit, and in some cases, won't actually
protect you against every possibility
of a cross-site scripting attack.
A more practical way to prevent these attacks
is to keep your browser and any associated applications always
up to date to the latest version.
This ensures that any security patches or bug
fixes will be implemented, and hopefully those
will be fixes that will avoid these types
of cross-site scripting problems.
And if you're a developer, the ultimate fix for this issue
is to validate all of the input that is
provided to your application.
If you're looking for someone to add their own script,
you can stop and filter out any of that information
before it's interpreted by the application.