A cross-site scripting attack, also known as XSS, is one of the most common web app vulnerabilities that has been around since the early days of the World Wide Web.
In this type of malware attack, an attacker exploits the interaction between users and a vulnerable application to inject malicious scripts into web applications. They will dupe the browser into executing malicious scripts in the context of the domain of a victim.
Common methods utilized in this attack include stealing the domain's cookies, modifying or deleting its contents, and engaging in other illicit activities.
Usually, XSS vulnerability occurs when there are untreated inputs and bad cookie usage. Let us take a case scenario of what happened on Myspace:
A MySpace user found an XSS vulnerability on the site and wrote a payload called “Samy Worm”. This payload was a stored XSS, which was first uploaded on his profile. When a user visited his infected profile, then the visitors saw the following text: “but most of all, Samy is my hero.” Meanwhile, the vulnerability managed to replicate itself onto the victim's profile, allowing the "Samy Worm" infection to persist and spread unhindered. The creator had found it funny until his house was surrounded by police, and he was arrested.
Samy wasn’t targeted at executing any serious damage, but we have seen the ramifications that can be caused by XSS attacks.
In 2018, for example, British Airways was affected by a breach attributed to XSS. The attack was executed using a technique known as card skimming, where a hacker injects malicious scripts designed to steal sensitive user data via web forms.
Interestingly, XSS vulnerabilities are hitting the biggest businesses around the world harder, including top sites like Facebook and Steam. In 2020, one researcher found an XSS vulnerability affecting the ‘Login with Facebook’ SDK commonly used by other sites to authenticate users. A similar bug had also been found in Gmail.
Now, an XSS attack will often take two key steps, with the target being the users of the app:
The attacker is then able to bypass the same-origin policy designed to separate different websites from each other. The attacker will often impersonate a legit user of the site. They can carry out user actions via impersonation. It gets even worse if the user has escalated privileges; the attack can take full control of the app!
The variety of attacks based on XSS is countless. Therefore, the number of symptoms is also limitless. However, the most common is inappropriate popup messages.
It’s not a symptom, but worth mentioning that outdated CMS systems make servers much more vulnerable to cross-site scripting.
There are different types of XSS attacks, mainly divided into three broad categories:
More than a decade after the Myspace scenario, XSS vulnerabilities have become quite prevalent! XSS vulnerabilities are now in the top 10 critical security vulnerabilities affecting businesses.
They affect the vast majority of web applications. For example, more than 50% of the vulnerabilities in websites in 2015 were XSS-related.
According to a 2020 report compiled by the Common Weakness Enumeration (CWE), XSS ranks top among the Most Dangerous Software Weaknesses.
A report by HackerOne found that XSS flaws accounted for 18% of all reported cybersecurity issues in 2020. In fact, the bounties paid by companies for these bugs rose by 26% compared to 2019.
Research has also shown that XSS attacks tend to target the Entertainment industry. A case scenario is an XSS attack on Fortnite, a popular online video game. Through an inactive webpage, the attackers could access the private data of 200 million Fortnite players without needing any login information.
The Finance, Education, IT, Government and the Transport sector are also popular targets. A 2019 Akamai report showed that 75% of attacks on financial services target APIs directly. A total of 50.7M attacks targeting financial services were XSS-related.
The most effective way to block website cyberattacks is at the application layer using a Web Application Firewall (WAF) and to pay attention to user input processing, particularly things like cookie handling.
If you can, use the httpOnly flag to store confidential data (e.g., sessionID). This way, the cookies can’t be read with this flag on the client-side.
We can’t reiterate this enough; ensure you filter all your user input data. Keep an eye on HTML tags, opening and closing signs.
Our ultimate WAF solution with ModSecurity could be just what you need to solve all of your XSS challenges. The BitNinja WAF 2.0 operates between visitors’ web browsers and your web server.
To keep you secure from the latest threats, we constantly patch new kinds of CMS vulnerabilities by adding new WAF rules to the rulesets. We also include automated false-positive reporting, which allows you to fine-tune the settings if needed, and we guarantee a low false-positive rate with the pre-defined rulesets.
Need a little help to configure the WAF? Contact our ninjas for support, and they will be more than happy to help you.
Prior to enabling all these rules, it is important to remember that doing so can lead to false-positive results when applied to poorly coded webpages. But if you are confident and you know what you are doing, then just go ahead.
It is quite easy for an attacker to inject an XSS payload through an untreated input like a GET parameter in a URL or a POST parameter as a form input if you didn’t sanitize angle brackets, single or double quotes and it can infect your HTML or JavaScript code. Take an example using this classic payload:
<script>alert(1)</script>
Single and double quotes can cause XSS vulnerability because these can influence the closing and opening of the expression.
Example for HTML:
<input type="text" name="username" value="john" onfocus=alert(1) autofocus "">
Example for Javascript:
<script>
var name = ’john’;alert(1);'';
</script>
If your website is vulnerable to XSS, this short JavaScript code will cause an alert pop-up on your site. It means that anyone can run any JavaScript code on your webpage.
In most cases, these payloads run on the client-side, and here is the problem; an attacker can run any JavaScript on a vulnerable page. Among other things, they can steal data and even impersonate the victim!
If the httpOnly flag is not used for cookies on your site, then it means these can be read on the client-side. An attacker can steal session information from cookies with an XSS, giving access to an account - unauthenticated!
SSL certificates are by no means a way to protect against XSS attacks. Regardless of whether the client-server traffic is encrypted or not, the web applications will continue to function in the same manner. The only difference is that the attack will take place in an encrypted connection.
Cross-site Scripting (XSS) attacks are one of the most common issues in cybersecurity and can have serious consequences, such as loss of customer trust. Cybersecurity is not optional anymore. It is a must! If you haven't tried BitNinja yet, don't forget to register for the 7-day free trial! No credit card needed!
We are always happy to help you! If you have any questions, check out our Knowledgebase, feel free to ask at info@bitninja.io, or you can even reach us on the Dashboard chat!
Let's make the internet a safer place together!
