How Cross-Site Scripting (XSS) Attacks Threaten Your Website and How You Can Stop Them
Jeffrey Edwards
|Cyber Risks & Threats | October 06, 2022
When we think about cyberattacks, we often imagine complex, organized hacks on IT systems or network infrastructure belonging to large corporations or nation-states. In our Hollywood-influenced collective consciousness, hackers wear hoodies and they go after high-value targets with sophisticated attacks on network infrastructure and IT systems.
But while attacks like that do happen, the truth is that, like any criminal, hackers most often go for the easy target. And, more often than not, the easiest target is a vulnerable customer-facing website, where attackers can steal large volumes of consumer data.
One of the most prolific methods of attack against websites is the cross-site scripting (XSS) attack, wherein attackers load malicious scripts onto trusted websites in order to redirect the customer journey or steal data.
In this article, we’ll tell you what XSS attacks are, how they work, how they threaten businesses, and how you can protect your website against them.
What is cross-site scripting (XSS)?
Cross-site scripting (XSS) is one of the most well-known and widely used web application attacks, but it’s also a bit of a misnomer. The name comes from early versions of the technique, where attackers were focused on stealing cross-site data, but the modern iteration of the technique is actually a type of injection attack. Typically, attackers insert malicious script–often JavaScript–into a legitimate, trusted website or application, which then carries that malicious code onto the user’s browser, giving the attacker full control to observe user behavior, access cookies, load fake or external content, and steal sensitive data.
How Do Cross-Site Scripting Attacks Work?
Cross-site scripting attacks work in two steps. First, the attacker must find a way to injected malicious code into a website or application. This is typically done with JavaScript, but can also include HTML or any number of other markup languages.
[See how many bots are in your funnel with a free Invalid Traffic Scan.]
For this step to be possible, the targeted website must include user input directly on its pages without validating or encoding it. For example, user comments may be assumed to be text only, and are incorporated directly into the site’s code. In this case, an attacker could submit a comment containing JavaScript or HTML and alter the website.
In the second step of the attack, XSS leverages the browser’s inability to distinguish this malicious script from legitimate markup, and the attacker’s malicious script executes. From there, the attacker can leverage the script to carry out a variety of attacks, like reading local storage, accessing cookies, including stealing personally identifiable information (PII), phishing, or distributing malware.
Why are XSS Attacks Dangerous to Your Business?
Cross-site scripting (XSS) attacks are so common that they’ve remained in the OWASP top 10 since their inception, but don’t underestimate them as an unsophisticated threat.
In a basic XSS exploit, an attacker may simply steal session cookies, but this is still a theft of PII, and a major violation of privacy laws like the EU’s GDPR and California’s CCPA. And, since the theft takes place on your website, you are responsible.
If sensitive data, like healthcare records or bank transactions is involved, the impact could be even more serious.
In one infamous example, the Magecart hackers used a form of XSS to breach computer hardware and electronics eCommerce retailer Newegg’s website by injecting malicious JavaScript onto a page hosted on ‘secure.newegg.com’ that was presented during checkout, and using that code to scrape customer payment data. That information was then sent back to a domain, ‘neweggstats.com’ owned by the hackers. The stealthy nature of the attack allowed it to persist for over a month, during which thousands of customers’ data was stolen.
These kinds of attacks not only bring regulatory penalties and threats of legal action, they can have disastrous implications on customer trust. In a recent survey, 87% of consumers said that they wouldn’t do business with a company that had a recent data breach.
What Are the Different Types of Cross-Site Scripting Attacks?
There are two primary kinds of XSS attacks, Stored attacks, and reflected attacks, as well as a third, less common variety called DOM-based attacks.
Stored XSS Attacks
Stored cross-site scripting attacks, also known as persistent XSS, occur when attackers inject a malicious script, or payload, onto an application or website so that it is permanently stored on the server, thus causing it to serve all future users the malicious code.
Because this method persists after the initial action from the attacker, stored XSS is the most popular form of cross-site scripting.
Blind XSS vulnerabilities are a variant of stored XSS attacks that occur when the attacker input is saved by the web server but executed elsewhere, whether in the backend of the application or in another application altogether. For example, if an attacker injects malicious code into feedback forms, the script will execute once the admin of the application opens the form.
Reflected XSS Attacks
Reflected cross-site scripting attacks or non-persistent XSS attacks occur when the payload is reflected off of a web application into a user’s browser. Typically this is done through a malicious link, which is embedded in a third-party website, such as in a comments section, and which initiates an XSS request to a vulnerable website to reflect the attack back to the user. While a reflected attack does not require the attacker to find a website with an XSS vulnerability, it will not work unless users click on the link, and thus has a lower success rate than stored XSS attacks.
DOM-Based XSS Attacks
DOM Based XSS or client-side XSS is an XSS attack in which the attacker modifies the DOM environment in the victim’s browser to execute the payload.
How Can You Prevent XSS Vulnerabilities?
Cross-site Scripting vulnerabilities are one of the most common web application vulnerabilities, but luckily, it’s typically easy to tell if your website is vulnerable to XSS attacks, and simple attacks can be addressed by basic best practices.
Manual Code Reviews and Pentesting
Code review is always necessary when building a web app or website. You should audit to source code manually to identify security vulnerabilities, and perform a penetration test to find further issues.
Specifically, you should identify code that outputs user input, and ensure that the output is properly sanitized. Any HTML output involving user input should be encoded, as should URLs be.
For those looking for guidance on code reviews, OWASP offers an in-depth guide on code reviews, complete with specific sections on XSS attacks.
Filtering User Inputs
A simple way to lower your chances for XSS attacks is to filter all user input to remove dangerous tags and attributes like <script>, <body>, <html>, etc. However, it is not advised to rely on filtering as your only defense against XSS attacks, as sophisticated attackers can leverage techniques like hex encoding, and Unicode character variations to bypass filters.
Use Escaping Techniques
Another popular technique for mitigating XSS vulnerabilities is using escape techniques, which signal to the browser that data should not be interpreted as code. So even if an attacker is able to inject a script on your page, the malicious code cannot be executed. Escaping techniques vary across different languages like HTML, JavaScript, and CSS, and must be implemented for each one that is present on your site.
Writing code for escaping user input is a time-consuming and tedious process, so it’s recommended to leverage existing libraries like OWASP ESAPI or Microsoft AntiXSS to build out your escaping capabilities.
Inject Code Yourself
If you suspect XSS vulnerabilities, you can often confirm them by manually injecting a harmless script to check if your browser will execute it. The alert() function suits this purpose well.
Use a Content Security Policy
A Content Security Policy (CSP) can also help mitigate XSS attacks. A CSP is an HTTP response header that lets you control what is allowed to load on your page, based on the request source.
CSPs can restrict inline scripts, remote scripts, unsafe JavaScript, as well as form submissions. However, CSPs are not adequate as a sole defense against XSS attacks, and are not a replacement for secure developing. If a web application isn’t properly coded for user input script malicious data can still escape and inject its own code into the existing script. Account frameworks Angular and AngularJS will also create challenges. Finally, not all browsers support CSP policies.
Protect Yourself from XSS Attacks with Go-To-Market Security
There is no silver bullet against XSS attacks, it is an evolving problem that requires a multifaceted solution. The solutions above can help organizations secure their properties against XSS attacks, but cannot guarantee success.
OWASP recommends a defense in depth posture, also known as layered defense, in which multiple, redundant layers of security safeguards and risk-mitigation countermeasures are employed.
To prevent XSS incursions, it’s imperative to be aware of all code running on your website, especially third-party code. Security assessments should be performed regularly, systems should be patched, and vulnerabilities should be addressed. Client-side protection should also be considered to allow you to unilaterally block scripts from unapproved sources, audit new scripts in real-time, and block injection-based attacks.
Author
Jeffrey Edwards
Content Marketing Manager
Jeff is the resident content marketing expert at CHEQ. He has several years of experience as a trained journalist, and more recently in his career found a knack for communicating complex cybersecurity topics in an approachable yet detailed manner.
