Attackers can often use our browsers against us. In this video, you’ll learn how a browser vulnerability can provide an attacker with access to a third-party website.
In this video, we’ll talk about cross-site scripting. And you may see this also abbreviated as XSS. It seems like we would use the abbreviation CSS for Cross-Site Scripting. But that abbreviation has already been taken by cascading style sheets. So instead, we use XSS to be able to differentiate between both of those technologies. This attack type was originally called cross-site scripting because of vulnerabilities that we found inside of our browsers. These vulnerabilities created a situation inside of your browser where information from one site could be shared with another site.
Cross-site scripting is one of the most common vulnerabilities for web-based applications. This takes advantage of the trust that the browser has for different websites. Although there are challenges in creating a cross-site scripting exploit, once you have that exploit, there are many different ways to take advantage of it. Many of these cross-site scripting vulnerabilities are based around an attack using JavaScript. JavaScript is a very popular scripting language within our browsers, and practically everyone has JavaScript enabled in their browser.
From a high level, let’s see how a cross-site scripting attack might be exploited. Let’s start with the victim, that would be our system, a trusted website that we might commonly associate with, and of course, there is the attacker. One way that you could exploit a cross-site scripting vulnerability is for the attacker to send a link to the victim that has a malicious script inside of it. This could be sent over email. It might be a text message or any other method that would get that malicious link into the hands of the victim.
The victim will click the link inside of that message, which takes them to a legitimate site, and it’s one that’s trusted by the victim. But because the attacker has provided this link, there’s additional information included with this connection. Usually, it’s a malicious script that’s also running along with the connection to the trusted website. This malicious script is not usually seen by the victim. But behind the scenes, there’s data that’s being sent directly to the attacker. This might include cookie information, session details, other specifics on that particular website, and anything else that may be considered private or secure information.
One common type of a cross-site scripting attack is a non-persistent attack. This might also be called a reflected attack. This is one where a third party website might be configured in a way that would allow people to run scripts inside of these user input blocks. A website like this one providing a search engine should not allow someone to run their own JavaScript within that input box. That’s exactly what has been found here by an attacker.
The attacker is going to email that link that takes advantage of that vulnerability. And behind the scenes, that script is going to send those private details to the attacker. So the attacker is the one sending the malicious code to the user, but the user is the one executing that malicious code against a third party website. The third party website may send session ID information to the attacker, which means the attacker will now have the same access to that third party website as the victim’s machine.
Here’s an example of a website that has a cross-site scripting vulnerability. This is one that has a shopping cart in it. And you can see there are a number of items within the shopping cart. And on this particular site, it’s the credit card number field that does not do any type of checking for scripts, which means we could embed a script within that credit card number field to be able to perform this cross-site scripting attack.
So here, I’ve created a very small amount of JavaScript. It’s a very simple script that simply puts an alert message on the screen. And that alert message shows your session information and then the session ID within the cookie for this site. So when we’re putting in credit card information, we would also include that entire script along with the credit card details. And you can see we’ve pasted it in on that credit card field.
When we click the Purchase button, a message appears on the screen with the information about our session, and it includes the session ID. Now obviously, the attacker is not going to have a session ID message pop up on your screen. Instead, that session ID will be sent directly to the attacker behind the scenes. And the victim has no idea that session information is now in the hands of the attacker.
Instead of the attacker trying to find some specific way to directly send a link to a user, what if the attacker simply posted the link on Facebook? This is the idea behind a persistent or stored cross-site scripting attack. The attacker will post a message on a social media site, and it will include with that message the malicious payload, which is probably malicious JavaScript. This is why it’s now called persistent because the attacker has now stored that information on that third party social networking site.
Everyone who visits that page with the malicious software will effectively have that code run inside of their browser. From the attacker’s perspective, this means that they’re effectively attacking everyone who visits that social networking page. So all of the viewers of that information will have that JavaScript run inside of their local browser. And because this is a social networking site, the attacker might include other code that would allow people to share their malicious code.
So anyone who views this message can have it posted to their own feed on that social media site. And the next person that views it on their feed goes through the exact same process and again and again as this message has now spread to all of these different users using a persistent or stored cross-site scripting attack. An interesting cross-site scripting attack was found in June 2017 by Aaron Guzman. He’s a security researcher who was looking at the Subaru front end on their website that allows them to manage different capabilities within their vehicle.
When you log into the Subaru website, you get a token. And this token never expires, which from a best practices perspective is probably not the best idea. Normally, there would be some expiration. For instance, the token might expire in a day, which would require you to log in again after 24 hours. Not only was there no expiration associated with this token, the token allowed you to perform any service request on your vehicle. Not only did this create a security concern for your vehicle, but you could add your email address to someone else’s account and the same token would allow you access into managing their vehicle as well.
The cross-site scripting part of this is a vulnerability that was also on the Subaru website, which means an attacker could send a link with malicious code inside of it and receive the token for that particular Subaru website from the victim. And now since we know that this token has such power, as soon as the attacker has that copy of a user’s token, they’re able to use it forever because the token doesn’t expire.
And if the attacker adds their email address to another Subaru account, that same token will also grant them access to that account. This is effectively a single token that allows an attacker full access to anyone’s vehicle that may be registered on the Subaru website Fortunately, this particular vulnerability was found by a security researcher who informed Subaru of the issue, and they were able to resolve and remove these vulnerabilities.
There’s a few things we can do to protect ourself against a cross-site scripting attack. One of these is to not click a link that you may not already trust. You should not click links inside of your email, your messages, or anything else that’s coming from a third party. Instead, you should open a browser separately and only type in domain names that you can trust. You may want to consider either disabling JavaScript or limiting the capabilities of JavaScript. Sometimes, you can do that with a browser plugin. But this offers limited protection and ultimately, it may limit what websites you’re able to visit.
Perhaps most importantly, you should always make sure that your browser and your applications are always updated to the latest version. As manufacturers locate and identify these cross-site scripting vulnerabilities, they will push out patches to prevent your browser from being susceptible to these problems. And if you’re an application developer, you need to make sure that all of the inputs to your application are checked to make sure that a user can’t add their own script to any of these input fields.