Browser security flaws can allow information to be inappropriately shared between web sites. In this video, you’ll learn about the different types of cross-site scripting and how to protect yourself against XSS.
<< Previous Video: WPS AttacksNext: SQL Injection, XML Injection, and LDAP Injection >>
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.