Cross-site Scripting (XSS) attacks have been around pretty much for as long as we’ve had web applications that help site owners create dynamic, functional websites. But even the first XSS attacks were observed back in the 1990s, right now, well into the 21st century, cross-site scripting continues to be a problem.
Today, we’ll figure out what cross-site scripting does, why hackers love it so much, and what prevents site owners from eliminating it.
The State of Cybersecurity
Perhaps the problem starts with the question of responsibility. You could argue that in the 21st century, even novice users should be aware of the major online threats surrounding them. You might even go as far as thinking that they’ve only got themselves to blame if they follow a suspicious link and end up with their data stolen.
Every website owner should take great care of their user data. Still, the current state of cybersecurity shows that isn’t really happening. We’re seeing successful attacks on websites every day, and the cybercrime community shows no signs of slowing down.
According to a PreciseSecurity survey from 2019, more than 72% of all cyberattacks target websites, and of them, more than 40% try to exploit cross-site scripting vulnerabilities. PreciseSecurity reveals that XSS attacks are the hackers’ favorite weapon.
What is Cross-Site Scripting?
The cleverness of a cross-site scripting attack is that the action takes place on the user’s device. Effectively, the attacker uses a vulnerable website as a vehicle to deliver a malicious script to the user’s computer. Because the script comes from a genuine website, the browser executes it without questioning its legitimacy.
The threat has been around for so long, and hackers know very well how to test potential targets for XSS vulnerabilities. An attack can be organized on the cheap as well, while the potential payout is very lucrative.
XSS attacks can use pretty much any client-side programming language you can think of, but criminals focus primarily on JavaScript. Some may find this a bit strange, given the controlled environment JavaScript files are executed in and their limited access to the operating system.
Yet, the truth is, cross-site scripting attacks that employ JavaScript are far from innocuous.
For example, JavaScript-based XSS enables website defacement because the malicious script can modify the content displayed by the browser. In more severe cases, attackers can alter a press release or change a product’s documentation to ruin the company’s reputation.
Usually, however, XSS attacks target users and their data.
Although JavaScript runs in a relatively isolated environment, malicious scripts in JS can use HTML5 APIs to access the victim’s microphone, camera, and geolocation. It can also trigger HTTP requests to arbitrary locations, potentially deploying malware on the victim’s system.
Hackers use XSS attacks for session hijacking and account takeover as well. JavaScript has access to the website data saved by the browser. This includes cookies that contain session tokens – the bits of information that keep you logged into your account and eliminate the need to fill in your username and password for every server request.
With the session token, hackers can pose as you without knowing your login credentials. From then on, taking over the entire account is as easy as pie.
Types of Cross-Site Scripting
As always, hackers have many different attack vectors to choose from when launching an XSS attack.
In some cases, they use social engineering and spam to make users click on a forged link or visit a particular URL. In others, they compromise the web application and wait for the users to flock and inadvertently execute the malicious scripts.
Depending on the setup and stages the attack goes through during its execution, you can determine three distinct types of cross-site scripting:
- Stored XSS attacks
In a Stored XSS attack (also known as a Type-1 or persistent XSS attack), the attacker injects the malicious script (or payload) and saves it in the web application database. During a request to the website, the hacker’s script is executed alongside the site’s legitimate code.
There is a subset of stored XSS attacks called Blind XSS. The difference between a regular persistent XSS attack and a blind one is that with the latter, the hackers’ intent is to execute the payload in the web application’s backend. In other words, it’s usually aimed at the site administrator rather than the users.
- Reflective XSS attacks
In Reflective XSS attacks (known as Type-2 or non-persistent XSS attacks), the attackers don’t store the payload in the application’s underlying infrastructure. Instead, it is reflected off the web server as a response to a specifically crafted request.
The number of websites affected by reflective XSS vulnerabilities is much higher, and this type of attack is much more common. Unlike stored cross-site scripting, successful reflective attacks usually include some form of social engineering and don’t affect all users.
- DOM-based XSS attacks
DOM-based XSS attacks also rely on a user clicking a link constructed by the attacker.
The payload is embedded into the malicious URL and is passed to the browser’s Document Object Model (DOM), where it’s executed because. This happens because the browser assumes the request is coming from the web application.
The worst thing about DOM-based cross-site scripting is that traditional XSS countermeasures don’t work for this type of attack. Over the years, browser vendors have tried to implement XSS protection mechanisms, but their success has been limited.
Especially when it comes to DOM-based attacks, the only way to protect users is to follow some best practices during your website or app development process.
What to Do in Case of Cross-Site Scripting?
From a user’s perspective, detecting a cross-site scripting attack is extremely difficult. The XSS operation is usually on the down-low, and the victims rarely realize they’ve been hit until their account has already been taken over.
Worse still, the simple act of visiting a seemingly benevolent website can trigger a persistent XSS attack. Still, you can set up a secure environment by keeping your browser up-to-date and using only reputable security products.
When it comes to XSS attacks triggered by maliciously crafted URLs, the regular security best practices apply – be extremely careful with the links you click, and take everything with a pinch of salt.
As a website owner, it’s up to you to ensure malicious links and vulnerable web applications are as few and far between as possible. Here are some of the most important things to consider:
1. Write secure code.
It all starts with the app’s initial design. You can find online guides that will help you build an application that processes user input more securely and enables you to develop better protection against cross-site scripting from the get-go.
2. Run regular security audits.
Even if you follow all coding best practices, even the smallest mistake during the core development or an update can inadvertently introduce an XSS vulnerability. By regularly scanning the app for security loopholes, you can quickly identify the bug and fix it before it becomes a real issue.
3. Install all available updates.
Most active websites are based on open-source content management systems like WordPress. Using them gives you a better chance of protecting your site against XSS, as there’s an entire online community identifying and patching security vulnerabilities for you. Of course, it’s still up to you to make sure all updates and security patches are installed sooner rather than later.
4. Set up a web application firewall.
A properly configured web application firewall (WAF) doesn’t eliminate the need to complete the steps above. However, such a tool can identify and block activity that seems like a cross-site scripting attack, giving your site an extra layer of protection.
The Role of Your Hosting Provider
Nobody wants to see an XSS attack on their site.
If it happens, the consequences are for both the users and the brand’s reputation. If you are using a shared hosting service, your host won’t be too happy to find infected and hacked websites on their servers either.
In most cases, if hackers manage to execute a cross-site scripting attack on your website, and your hosting provider finds out – it will simply take your site offline and keep it down until you fix the problem.
However, a good host will do a bit more than that.
Hosting providers that really want to help their customers prevent XSS attacks have monitoring systems that detect suspicious behavior in real-time. This way, the account owners are alert and can stop the attack before it affects too many users.
There are some limits to how much your host can help.
The provider won’t develop your application for you, and neither can it patch security holes in your website. However, if you choose the right hosting provider, you will be able to rely on a team of support specialists who can guide you in the right direction should you need more help.
Conclusion
The fact that more than twenty years on, the online world is still struggling to eliminate cross-site scripting is a testament to the attack’s effectiveness. There’s nothing to suggest a one-size-fits-all solution is coming our way, so as a website owner, you need to be aware of the threat and do everything you can to mitigate the risk.
Luckily, there’s plenty of information on how to run your application more safely. Building better defenses against XSS attacks is more accessible than ever.
FAQ
Q: What is a cross-site scripting attack?
A: In a cross-site scripting attack, a vulnerable web application returns an unexpected response based on unsanitized user input. As a result, attackers can use the app to execute malicious scripts on the target’s computer.
Q: Why is cross-site scripting so dangerous?
A: Hackers love XSS vulnerabilities because they often end up offering versatile attack vectors. Although JavaScript is the most popular programming language used during cross-site scripting attacks, vulnerabilities can be exploited in many other coding scripts. Javascript might have relatively limited access to the victim’s operating system, but criminals can still use it to distribute malware and effectively deface the website.
Meanwhile, thanks to the free access hackers get to the user data and cookies, XSS is also an excellent account takeover device.
Q: What are the three main types of XSS attacks?
A: Depending on how the malicious payload is executed, you can distinguish three main types of XSS attacks.
If the attacker manages to plant the payload within the vulnerable application, we’re talking about a stored (or persistent) XSS attack.
When the attacker uses a malicious URL to reflect the payload off the web application, you have a reflected cross-site scripting attack.
If the malicious script is loaded straight into the browser’s Document Object Model, the attack can be classified as DOM-based.
ScalaHosting – Cyber Attack Guide – Cross-Site Scripting
What is a VPS – Everything you need to know!
