A cross-site scripting attack takes advantage of the trust associated with our browser. In this video, you’ll learn how a cross-site scripting attack can be carried out and you’ll see a live demonstration of an XSS attack against a vulnerable application.
In this video, we’re going to talk about cross-site scripting. You’ll sometimes see this abbreviated as XSS. The reason we don’t refer to this as CSS, which would be cross site scripting, is because we’re already using that term for Cascading Style Sheets. So instead of being confused between what CSS we’re referring to, cross-site scripting uses XSS.
We originally called this cross site scripting because there were multiple sites involved due to browser security issues. Cross-site scripting allowed one site to share information with another site. Browsers today restrict any type of information exchange between different websites, but we are still able to inject these scripts using different mechanisms that we’ll discuss in this video.
You’ll also find that there are a large number of cross-site scripting vulnerabilities, and we’re constantly discovering new vulnerabilities with different applications. This type of attack takes advantage of the trust that a user has for a site. And as many of us have seen, once you log into a website, you are often trusted on that website for a certain amount of time. This cross-site scripting attack takes advantage of that trust to gain access to information that might be on that third party website.
The script in cross-site scripting is commonly associated with JavaScript, although this is not the only type of script that can take advantage of XSS. But almost all browsers use JavaScript, and very few people have disabled JavaScript from running inside of their browser. So many websites are using JavaScript to display information on the screen that completely disabling JavaScript is probably not a viable option.
Here’s a common implementation of cross-site scripting. We have you, the victim, that has your browser on your laptop. There’s a trusted website that you’ve probably already logged into, and then there is the attacker that is going to try to use cross-site scripting to gain access to this website that normally they would not have access to. First, the attacker needs to get this malicious script to the victim.
One very easy way to get scripts sent to someone is in their email inbox, so our attacker is going to send an email to the victim. And inside that email is a link that is going to run that malicious script. Once the user clicks that link, the link is going to redirect the user to this trusted website, and it’s going to run a script on that trusted website, the attacker is going to receive information from that trusted website. This might be information about the user’s account, or this script might take the user’s session cookie, send that session cookie to the attacker, and now the attacker has the same access to that website as the victim does.
Let’s watch a cross-site scripting attack take place in real time. I am on a website that is an intentionally vulnerable application through WebGoat. This is a shopping cart application. You can see there’s a few things in the shopping cart. And just like most shopping carts, you provide a credit card number and a three-digit access code, and you click purchase, and it goes through the process of purchasing whatever you have in your cart.
To get to this point, we’ve had to log into this website, we probably have an account already in place, and we might even have our credit card information already stored on this website. So now that we’ve logged in, there is a level of trust that we the victim have with this website that we’d like to buy things from. If the attacker knows this, they can send us a malicious script, either through email or some other method, that will cause us to send this information into this trusted website.
So the script that we’re going to run is the one that you see on the screen here. You can see it has simply an alert. Now, normally, we would not be seeing an alert on our screen, but for the purposes of understanding what’s happening behind the scenes, I’m going to have this alert message pop up on the screen. What would normally happen is the information would be sent directly to the attacker, rather than appearing on our screen.
This is going to show my session information, and it’s going to provide my session cookie on the screen. This is the cookie that would normally be sent to the attacker that they can then use to log in as if they were us. So let’s copy this information and we’re going to put it into any of these fields that we have on this particular website. I’m going to delete what’s already in one of these fields, and I’m going to simply paste in that entire script. And when I hit Enter, the script runs.
And as you can see, it says my session information, shows my session cookie, and now that information could be in the hands of the attacker. This would normally be sent to the attacker, and they now would have full access to this website as if they were logged in with my account. So they can purchase things, they can change account information, and they might even have access to my stored credit card information.
Another type of cross-site scripting attack is one where the script is always stored somewhere for people to access. We refer to this as a persistent cross-site scripting attack or a stored XSS attack. In a persistent attack, the malicious script is stored on a public web page, and anyone visiting that web page is going to run the script. It’s hard to detect this kind of attack because you don’t know who’s going to visit that particular web page. You might be able to focus in on a certain number of victims, or it may just be anyone who happens to visit that page.
Imagine on a social media site an attacker putting this malicious script, and now anyone who visits that particular page on social media now is running that script inside of their browser. One of my favorite cross-site scripting attacks was in 2017, where Aaron Guzman found a vulnerability with an automobile. Specifically, it was a Subaru. When you log into the Subaru website, each user gets a login token. We saw an example of that in the cross-site scripting attack that we did.
This token, however, never expires. Once you log in initially to the Subaru website, you are always logged in on that browser. This means if you could get the session token for any user that is logging in, you would have access to their account indefinitely. This means you might have access to change someone’s profile information, so you could change it from their email address to your email address. And in the case of our more modern automobiles, you might be able to change things in the car itself.
For example, from this web front end, you might be able to unlock all of the doors to the car. And of course, Aaron found that on the Subaru website, there was this cross-site scripting vulnerability in the web front end itself. Thankfully,. This vulnerability was not exploited by any attackers and was resolved thanks to the hard work from the research team.
One way to prevent a cross-site scripting attack is to prevent the script from running at all. So you should never click links inside of an email message or click any links on a web page that’s not trusted. You could also consider disabling JavaScript, but we use JavaScript so much on our modern browsers that it might not be a very useful way to browse the internet. Instead, you might want to use third party utilities that are looking for these type of exploits and will stop them in real time, instead of passing that script to another website.
Sometimes these type of attacks are due to a vulnerability in a browser or in an application, so keeping everything up to date may allow you to stop this problem before it even becomes an issue. And ultimately, application developers need to make sure that they validate all of the inputs that are being put into their application so that someone can’t run any type of script, malicious or otherwise. By making sure the application is secure, we can prevent any type of cross-site scripting attack from occurring.