If you can convince a browser to run a script, then you can control a significant amount of a user’s working environment. In this video, you’ll learn about cross-site scripting and how XSS attacks can be used to steal right from under our noses.
<< Previous Video: Data Injection Next: Cross-site Request Forgery >>
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-site 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.