So you think cross-site scripting isn’t a big deal?

Cross-site scripting (XSS) Vulnerabilities have historically been the most numerous class of web application security issues. They are easy to introduce but much harder to find and fix, which increases the risk of them ending up in production code. This is reinforced by the misconception that web security is about protecting the server, and since XSS can only affect the client, this is a low-risk vulnerability with limited impact.

In fact, cross-site scripting can be (and is) used by cybercriminals as a springboard to more elaborate attacks targeting end users. Simply put, if you have XSS vulnerabilities in your websites and applications, you are putting your users at risk and making the job of malicious hackers much easier. To illustrate how easy it can be, we asked an Invicti security researcher Sven Morgenroth for a snippet of JavaScript code that, while harmless on its own, could also be used for malicious purposes in a realistic attack scenario – and the findings are chilling.

Innocent but dangerous – an original code

If you are unfamiliar with cross-site scripting payloads, these are snippets of JavaScript code that can be injected into a vulnerable site, causing the browser to perform specific actions. “Malicious payloads often exploit bizarre browser behavior to evade built-in security checks,” Morgenroth explains. “A good example of this is how the beforeunload event is handled. It’s designed as a way to display a prompt before leaving a page to alert you to unsaved changes. You’re not supposed to use it for anything else or put custom code in the event handler, but browsers don’t fully enforce it, so you can find ways around it.

Turns out you can make an asynchronous function call using setTimeout(), and it will not be blocked by the browser. Instead, it will run just before the page unloads. Here is an example code snippet that triggers a redirect to example.comalthough it could be any other URL:

window.addEventListener('load', () => {
    window.addEventListener('beforeunload', function (e) {
        setTimeout(() => window.location = '')

“As soon as the page loads, the script adds code that listens to the beforeunload event and changes the page URL when that event occurs,” says Morgenroth. “So you have a piece of valid JavaScript that you can put on a webpage, and it will sit there waiting for you to click or type a different URL in the address bar. As soon as you do, the script will redirect you to an arbitrary site.

From cool ride to attack payload

While it’s great to trick the browser into unexpected behavior, you need to get the browser to load this code first. For an attacker, this could mean crafting a malicious URL and tricking a user into opening it. The sample code would also require a bit of work to turn it into an actual injectable payload. According to Morgenroth, “XSS payloads are usually encoded, sometimes more than once, to ensure they are accepted by the application and also to help evade filters. The code can also be minified to make it as short as possible.

However, first and foremost, to create the URL, attackers need to find a page that is vulnerable to cross-site scripting and therefore happy to accept the injected script. It must also be a page that someone would legitimately want to visit so that they can more easily be tricked into following a malicious link. If you have an XSS vulnerability in your web environment, cybercriminals can target your users or customers through one of your vulnerable sites – and with large organizations running more than a hundred sites and applications on averagethe odds of finding an opening are in favor of the attackers.

Let’s walk through a hypothetical but perfectly realistic attack scenario to see what can happen and how.

Realistic Attack Scenario: Phishing + XSS

After finding an XSS vulnerability on one of your sites, attackers prepare a spear phishing campaign targeting your company’s current customers. Using open-source intelligence (OSINT) or just a list of stolen customers, they send each of your customers a carefully spoofed marketing email announcing a new research report that promises to reveal revealing industry insights. . The message contains a button labeled Read the report now which points to your site, more specifically to a page like this:

The URL is very long and not displayed in full, so your client won’t see the encoded attack payload at the end (and it would be a random string of characters anyway). Importantly, this page has an XSS vulnerability that is ready to accept injected code – except this time the payload redirects users to but to a malicious site that tries to download malware by car.

The customer is unlikely to suspect the URL because it points to your site, which they know and trust. And if the phishing email is carefully crafted, everything can look legit, maybe even say it’s a PR agency on your behalf (as to why the e- email is from a different domain). If the report seems relevant, the customer clicks the button and an existing page on your site opens in their browser – and because the page is vulnerable, the malicious redirect code also loads, sitting quietly in the beforeunload event handler and wait.

Now comes the sting. When your customer realizes this isn’t the promised report page, they’ll assume that someone in marketing entered the wrong URL. So it’s likely that he’ll start clicking on your site to find that report (because he knows the site and trusts it). As soon as they leave the page, the listening script is triggered and they are redirected to a malicious site that installs malware in their browser or even their operating system. It can be anything – a botnet client, a cryptojacking script, a web shell for other attacks, or even a ransomware downloader.

One of your customers has just been hacked – and it looks like the attack came from your site.

The risk is real, and so are the consequences

Phishing attacks are among the top cybersecurity threats overall, having tripled in number since 2020. Although more commonly associated with credential theft attempts or various scams, phishing is also the perfect way to deliver XSS attack payloads, as cross-site scripting typically requires user interaction. the user (at least for the most common attacks). reflected XSS). The scenario presented here abuses the trust your customers have in your site and your brand to get them to click on a malicious link. Your vulnerable site is then the vehicle of an attack against one of your customers. So while it’s true that your own systems aren’t being attacked or affected in any way, your customers are at risk. Attackers can obtain sensitive data, rewrite your page content in the browser to misinform users, or even hijack a user session to access restricted information or systems.

A simple redirect is just one example of what an XSS payload can do. Depending on the specific vulnerability and payload, hackers have many other options to choose from. For example, instead of an immediate redirect, the same attack could start by rewriting your business page as it loads and presenting a perfectly plausible message like Redirecting you to If the page doesn’t load in 5 seconds, please click the link below or manually paste the URL into the address bar.

Not one but two malicious redirects could then be hidden on this rewritten page. One would be triggered by the click event on the link so that if you hover over the link to check it, you see a safe URL – but when you click it, you land on a malicious page. For the other redirect, we have our old friend, the beforeunload event, to catch you when you type or paste the URL. The user has the illusion of having a choice but, in any case, he finds himself on a malicious site which can harm him.

So while it’s technically true that XSS attacks only affect the client browser, the consequences to your business and reputation can be severe. Especially with a coordinated phishing campaign, attackers rely on your customers’ trust in your business – and by having exploitable XSS vulnerabilities in your sites or applications, you undermine that trust. In this specific example, you might even be required to carry out investigations to prove that your site was not the source of the attack, and you are not liable for damage to your customers’ systems and data. And even then, your relationships with your customers are likely to deteriorate, and regaining trust and reputation could be difficult and costly.

Don’t put your users at risk – fix these XSS issues

“In the past, cross-site scripting vulnerabilities were treated as a necessary evil in web development, not as serious flaws,” Morgenroth concludes. “Code reviews and manual penetration testing were the only ways to find XSS, so it took a lot of work and time to fix what was considered a relatively minor issue.” Today, advanced tools for dynamic application security testing (DAST) can automatically and accurately identify all kinds of XSS vulnerabilities in any number of sites, so cracking down on cross-site scripting is finally a realistic prospect.

As discussed in this article, leaving XSS vulnerabilities in your web applications means putting your customers and your reputation at risk. Fortunately, with modern advancements in vulnerability scanning, your developers can finally reduce their XSS backlog by getting actionable reports that help them implement long-term fixes and avoid the same errors in the future. You don’t have to wait for the next penetration test – scan for vulnerabilities as often as you like, from your early builds to your production deployment, and fix reported issues.

With a cutting-edge vulnerability scanner like Invicti, XSS vulnerabilities are low-hanging fruit for quick and meaningful security improvements. So find them and fix them. No more excuses.

The post office So you think cross-site scripting isn’t a big deal? appeared first on Invicti.

*** This is a syndicated blog from the Security Bloggers Network of Invicti written by Zbigniew Banach. Read the original post at:

Amanda J. Marsh