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.
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.
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.
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.
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.
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.