A cross-site scripting attack allows an attacker to obtain access to a trusted third-party website. In this video, you’ll learn about cross-site scripting and view a demonstration of a cross-site scripting attack.
In this video, we’ll look at ways that cross-site scripting can be used to take advantage of vulnerabilities with an application. You often see cross-site scripting abbreviated as XSS instead of CSS, which you might expect from cross-site scripting. However, the CSS abbreviation has already been used by cascading style sheets. So we use XSS to specify cross-site scripting.
We call this cross-site scripting because we’re able to take information from one site and share that information with someone else. This is caused by vulnerabilities that might exist within a browser, which is why it’s another good reason to always have your browser updated to the latest version. Although the browser is part of the equation, the software that’s running inside of the browser is the other part of this equation.
If someone was to write code that would not allow a cross-site scripting, it could be stopped within the code of the application itself even if the browser was vulnerable. This is a relatively complex vulnerability that’s difficult to identify unless you already have knowledge of the code that’s being used. So if somebody is developing a web based application, they would need to look in their code to avoid any type of cross-site scripting vulnerability.
If you think of this in very broad terms, you could say that cross-site scripting is malware that takes advantage of vulnerabilities with JavaScript inside of your browser. And although you may think that disabling JavaScript in a browser would resolve this issue, every website you visit has some amount of JavaScript running that’s important for the operation of that site. So simply disabling JavaScript is probably not the most effective way to deal with this issue.
The first step in taking advantage of a cross-site scripting vulnerability is to run some type of script inside of a user’s browser. This might be a search box or some other type of input in a web based application. This exploit commonly takes the form of an email that is sent from the attacker to the user. The user clicks a link inside of that email that then runs a script that takes private information such as user credentials, session ID, or other sensitive details, and it sends that information to the attacker.
This script executes in a browser as if it came directly from a web server. But in reality, the attacker has added their own JavaScript into this particular link. And once this session ID or user credentials have been sent to the attacker, they would now have access to the account that you were using on that website. Let’s perform a cross-site scripting attack.
In this case, we’re going to perform it against an application that is vulnerable on a website that provides a checkout process through a shopping cart. You can see that I have a number of items in the shopping cart. There is a total amount of money that will be charged to my credit card. We’ve also got credit card numbers and input for the access codes and then a purchase button. Since we’re logged in to this website, an attacker could take advantage of that trust.
If the attacker just had the session ID, they would be able to put that session ID on their machine and effectively have the same login session from their browser. Let’s add some JavaScript to this page to see how an attacker might be able to retrieve that session ID. I have some JavaScript that I’ve created here. You can see it does a script alert. This one shows your session information and displays the session ID on the screen.
Obviously, the attacker would not be displaying this information on the screen. Instead behind the scenes, it will be sending that information to the attacker through other means. The end user would have no idea that the session ID was even collected by the attacker. So let’s highlight this and let’s copy it. Let’s now add that script to the end of the credit card number. And I’m going to click the purchase link. And now you can see that your session ID has been written to the screen.
This is the information that would go to the attacker. And once the attacker has the session ID, they can access your account from their browser. Now let’s perform another cross-site scripting attack. This one is called a persistent or stored cross-site scripting attack. In this case, we don’t have to worry about an attacker sending an email or having the user click something that’s in their browser.
Instead, we’re going to put the malicious code on a centralized server such as a social media site. The attacker could create a comment on the social networking site, and inside of that comment, place their malicious code. Anyone who visits that page or reads through those comments would effectively also be running that JavaScript in their browser. An email containing a link is very directed at an individual.
But something like a stored cross-site scripting attack on a social networking site is one that affects anyone who visits that page. This is something that could obviously spread very quickly, especially if there are many users to that site and many people viewing the page that has that comment. There have even been cases where cross-site scripting attack has been made against a car.
In 2017, a security researcher named Aaron Guzman was able to log in to the web based front end of his Subaru. From that web based front end, you’re able to perform a number of functions in the car itself. Once you log in, each user gets a session ID or a token that allows them access to their account. The first problem that Aaron found is that this token never expired. So once you logged in, your account was always available with that session ID.
Even worse, the session ID information was not properly validated. So you could use anybody’s email that had an account on the Subaru website include the token that you generated for your account. This effectively allowed Aaron full access to other people’s vehicles. Even if you didn’t own a Subaru, you could send an email with a cross-site scripting attack inside of it, have the user’s token sent to you, and now you could use that token for anyone on the Subaru website.
This was obviously a significant vulnerability and Subaru was able to correct their software to avoid this problem in the future. There are a number of different ways to mitigate a cross-site scripting attack. One is a rule that you should really apply to anything which is never click information that’s being provided to you inside of an email message. Since the details of what you’re clicking are effectively hidden from you, and in some cases, very difficult to know what you’re clicking on, the best practice is to never click any of those links.
As we mentioned earlier, you could simply disable all of the JavaScript inside of your browser. This will probably break most of the sites that you normally visit, and in some cases, won’t actually protect you against every possibility of a cross-site scripting attack. A more practical way to prevent these attacks is to keep your browser and any associated applications always up to date to the latest version. This ensures that any security patches or bug fixes will be implemented, and hopefully those will be fixes that will avoid these types of cross-site scripting problems.
And if you’re a developer, the ultimate fix for this issue is to validate all of the input that is provided to your application. If you’re looking for someone to add their own script, you can stop and filter out any of that information before it’s interpreted by the application.