Cross-Site Scripting – CompTIA Security+ SY0-401: 3.5


One of the more prevalent
and dangerous attack types is called cross-site scripting. We refer to this as XSS. There’s something already
called cascading style sheets that we use in our browser that
is a technology called CSS. So to make sure there’s
no confusion, whenever you see cross-site scripting
referred to we always use an X instead
of a C for cross. This is a word or a
term that was originally created because older browsers
would allow information from one browser window to
interact with the other browser window. And if those were
on different sites, you could essentially take
information from one website, or what you were in
putting on one website, and send it to another. And if the bad guy could hide
one of those browser screens and grab your
user-name and password and send it to another
site, well obviously, that is a security problem. These days our browsers
are much smarter than that. They’ve been programmed
so that they will not allow a lot of
cross-site communication. The bad guys are
always trying to find ways to go about doing this but
we have generically called now this methodology of scripting
information and sending it some or else, we’ve now called
that cross-site scripting. It’s a very common
vulnerability. It’s also not very
straightforward. It’s something
that you’re really trying to take advantage
of bad programming, of differences in how
websites are developed. So some websites might be
susceptible, others may not. It requires a lot of
research and a lot of testing to see if your
particular website is one that is susceptible to
cross-site scripting or not. You’ll find that a lot
of the malware out there is using JavaScript to do a
lot of it’s heavy lifting, and so cross-site
scripting generally uses a lot of JavaScript. But as the name implies, it’s
very generic– it is scripting. And scripting could
really be anything. But what we found
is that JavaScript is so powerful in our browsers
that the back guys tend to gravitate towards
JavaScript because it’s able to do a lot
of things for them. And if you have
JavaScript turned on, you are probably susceptible
to a large amount of cross-site scripting
vulnerabilities and attacks that are out there. It’s just one of
those things where you have to keep
your browser updated, you have to make sure your
web apps are updated so that you are not susceptible
to cross-site scripting. There’s two primary categories
of cross-site scripting attacks. The first one we’ll talk about,
our non-persistent cross-site scripting attacks,
you may also hear these referred to as reflected
cross-site scripting attacks. These are attacks that are
not part of a web page, these attacks are ones
that are emailed to you or you are enticed
to click a link that is going to run the script
that’s part of that attack. And it’s trying to take
advantage of vulnerabilities in user input on things like
a search box, for instance. You’ll get an email from
the bad guy and they’ll say, please click this link,
here’s a funny video for you, here’s things you
should look about. And that link is
going to take you to a website that runs this
cross-site script that then provides the bad guy with
information that they can use to perhaps gain access
to your account. So they’ll have you
login to Facebook, they’ll have you login to
your financial account, and it’s going to then–
behind the scenes– send your credentials, or
your session IDs, or some user information back to the bad guy. And then of course
from their desk they now have access
to your account, they can do whatever
they’d like. This is executing in
the victim’s browser. So they’re essentially
going to a website, and it’s the browser that is
now becoming the problem for us, it’s running exactly the
script the bad guy gave us and the browsers
happily handing off our credentials to someone else. That’s not exactly what
we’d like to have happen. When the bad guy has your
session IDs, your cookies, some of that really important
session information that they can use to
get into your account, they can now do a
lot of things and you have no idea that this happened. It all happen behind the
scenes because that script told it to grab that session ID,
send it off to the bad guy, and now they have access
to your information. Another type of cross-site
scripting attack is the persistent attack or
the stored cross-site scripting attack. This is one where
the script itself is stored on the web server. The bad guy doesn’t
have to send information in an email that has
the script inside of it, they’re going to post a
message on a social network or they’re going to post a
message in a forum somewhere and that message, as part
of that message that’s on the website, is going to have
that particular piece of script inside of it that then
attacks your computer. And now it is persistent. Everybody who goes to this
website gets the payload. So it’s a good way of affecting
many, many, many people all at once. There’s no specific
target here, you’re not emailing a specific
person and trying to get a specific
person’s information, it’s anybody who happens to
go to that website who happens to have a browser that is
susceptible to that particular cross-site scripting attack. And if this is a
social networking site, obviously there are many people
on these social networking sites, and these forums
it can spread very, very quickly it can be
propagated very, very quickly. And we’ve seen some very good
examples of this in the past. In October the fourth
of 2005, a gentleman named Samy Kamkar realized
that he found a way in Myspace to force people to
become his friend. So he thought this
would be a great way to build his friends list. You can have a lot of friends
because you can force people now to become your friends. So he wrote a little cross-site
scripting information and he posted it online. So this is a persistent
or stored attack that he had on Myspace. And what it did
was post a message that said, “but
most of all Samy is my hero” on the
profile of the victim and then it added them
as a friend to Samy. And so suddenly, once
it added as a friend, it posted the persistent
script to their own profile, it essentially became a worm. Everybody who saw it ended
up having that script copied to their profile, their friends
saw that script, all of them got infected with the same
thing and so on and so on. 20 hours later Sammy had
over a million friends as part of his Myspace
profile, and unfortunately he also had a felony. So part of the
problem with this is that he was
manipulating the system. It was a hacking attempt. It caused a lot of
problems for Myspace because this worm
was out of control. He essentially brought
down the Myspace service. He ended up having a plea
agreement to a felony. He got three years probation,
90 days community service, restitution that he had to
make to Myspace he actually had the ability to use a
computer taken away from him– he could not use a computer
or network device at all. Eventually that was
given back to him. He had that particular piece
of it erased from the record. And now he is a
security researcher. You can go out to YouTube you
can see some of the things he’s done with entrepreneurship. So now Samy is making
our networks safer and using this knowledge
that unfortunately got out on Myspace, he’s now using
it for the greater good. Let’s look at a
practical example of how somebody could use
this cross-site scripting capability to gain information
they would normally not have access to. Let’s take this example
right in front of us. This is something
called WebGoat. This is from OWASP, this is the
open web application security project. You can go on to
www.owasp.org and you can download this
very vulnerable web front-end called WebGoat. It’s a series of
examples of how you can try to take advantage
of some of these flaws. It’s essentially a badly
programmed website. And you can test and see how
some of these vulnerabilities are affected on a website
and try some different things yourself. So let’s try a cross-site
scripting problem ourself. Let’s say that we
are an employee. Let’s say that we are, if I
look at this HR department application, let’s
say that I am Tom Cat and I’m going to login
with my credentials. And in my credentials, if
I scroll down a bit here, you can see that I have the
ability to look at my profile. And my profile for HR has my
name, has my street address, has other information
inside of it. But I want to gain access
to everybody’s profile and I know that the person in
charge of the HR department does have access to
everybody’s profile. And inside of your profile you
can see people’s salary, what they make, you can get
credit card information. So having that
particular HR account might gain us information
that we normally would not have access to, and
probably shouldn’t have access to. Well, what we’re
going to do is embed a cross-site scripting attack
right in our own profile. Maybe I’m not even
Tom, maybe I’ve just gained access to Tom’s profile. I’ll use his profile
as a jumping off point. So I’m going to
edit this profile and in the street
address here I’m going to add some
additional text here and I’m going to put in here
and create a JavaScript. I’m going to write
here a script, and I’m going to inside
the script do an alert, and inside the alert I’m going
to put a session ID, and inside of that I’m also
going to ask this to add on the
cookie information. And in document, cookie. And inside of JavaScript–
that’s the way that you would add on some
additional cookie information– and I’m going to in
the script right there. So I’ve essentially added on
a little bit of JavaScript inside one of these fields
in this particular form. It probably should
not be working, this form should not
allow me to do that. But I’m going to
update this profile. In fact when this
profile runs, you can see the session ID
information is right here. We have a later video that
talks about session hijacking and how that particular
piece of information is a very, very valuable
piece of information. Well that’s good, now
I’ve embedded it inside of my profile. So I’m going to log out. Now I’m going to send a message
to the guy in charge of the HR department and say, could
you look at my profile? I think there may be
a problem with it. Please have a look, I
think there’s an issue. Well then if it’s coming
from Tom, who may be employee or it appears to be coming from
Tom who may be an employee, that’s something
that we really may be interested in making
sure that his profile is OK. So we’ll login as Jerry. I don’t think I’ve got the
right login name there. So we’re now logged
in as the HR guy. Notice the HR guy
has the ability to look at Tom Cat, Jerry
Mouse and Joanne McDougal’s information. So I have more information
available to me. But Tom sent me
an email that said he’s having problems
with his profile, let’s click on Tom’s name. I’m going to view the profile. That script runs and it runs
as the person in charge of HR, it runs as Jerry. The session ID is displayed,
if I was a bad guy instead of displaying that session
ID, I would send it to me. And if I have the session ID
of who’s logged in right now, I can essentially
pretend to be them directly to the web server. The web server
uses the session ID as a piece of information that
determines who’s logged in. So I wouldn’t need Jerry’s
user-name and password at that point to
hijack his session and be able to see
all of the information that he might have access to. All by planting a little bit of
script inside of Tom’s account now I can see everything
that Jerry can see. To protect against
cross-site scripting there’s a few things we should
just always keep in mind. One is, don’t click links
inside of your email. I say that over and
over and it’s something that pretty much everybody
should think about. There’s usually going to
be a link in your email, even if the link is
legitimate it should just be a best practice for you
to take that information, go to a browser, type it in
manually, and go to the site that you need to go to. You might want to also
consider disabling JavaScript or having it only run on certain
sites that you might trust. There’s usually
extensions, or add-ons you can get for
browsers, that what a allow you to do that on a per
page basis or a per site basis. You should also make sure
that your browser’s updated. If you’re in charge
of a web server, in charge of applications
on that web server, you need to also make sure
that all of those applications are up to date because
manufacturers and developers will find new ways that
people are taking advantage of these scripts and
they’ll patch them. So by having the latest version
of that on your web server you might be able to avoid it. If that HR department had
the latest version of that HR software, it may
have already stripped out any of that
scripting and they wouldn’t be susceptible
to that problem. By keeping your web
apps up to date, and keeping your browser up
to date, and the applications, and the operating
system on your computer, you can be assured that at
least those known cross-site scripting attacks are ones that
you can prevent and make sure that nobody takes
advantage of your browser.

2 thoughts on “Cross-Site Scripting – CompTIA Security+ SY0-401: 3.5

  1. Thank you Professor Messer. I just posted this video on my FB page to explain to my non-techie friends how their FB account PROBABLY got hacked. Hope it helps them from willy nilly clicking…

  2. Does turning off the Prevent Cross Site Tracking option in Safari increase the risk of XSS attacks on said device? I understand that the setting in general is primarily to prevent ad companies from tracking a users web usage but, by allowing for the option to further track cookies, etc, could the device be further at risk for their session ID and cookies to be compromised in the midst of a persistent or non persistent attack?

Leave a Reply

Your email address will not be published. Required fields are marked *