Cross-site scripting (XSS) is a type of security vulnerability typically found in web applications. XSS enables attackers to inject client-side scripts into web pages viewed by other users and may be used to bypass access control, such as the same-origin policy.
The impact of XSS can range from a small nuisance to significant cybersecurity risk, depending on the sensitivity of data handled by the vulnerable website, and the nature of any mitigations implemented.
Table of contents
- How does an XSS attack work?
- Why is XSS dangerous?
- What are the types of XSS attacks?
- The difference between server-side and DOM-based cross-site scripting
- How to prevent XSS attacks
- How UpGuard can help reduce web risks
How does an XSS attack work?
There are two stages to a typical XSS attack:
- Attacker finds a way to inject malicious code into a web page that the victim visits
- The victim visits the web page and the malicious code is run
For step one to work, the vulnerable website must directly include unsanitized user input on its pages. The attacker then inserts a malicious code into the web page that is treated as source code by the victim's browser.
There are other XSS attacks that rely on luring the user into executing the payload themselves, using social engineering.
Why is XSS dangerous?
What are the types of XSS attacks?
There is no single, standardized classification of the types of cross-site scripting attacks, but most experts distinguish between at least two primary types: non-persistent and persistent. Other sources further divide these two groups into traditional (caused by server-side code) and DOM-based (in client-side code).
Non-persistent (reflected) XSS attacks
Non-persistent (or reflected) cross-site scripting vulnerability is a common web vulnerability.
Typically the result of data being provided by a web client, most commonly in HTTP query parameters (e.g. a form submission), and immediately used by server-side code to parse and display a page of results to the end-user, without properly sanitizing the content.
For reference, sanitizing refers to the process of examining an HTML document and producing a new HTML document that preserves only whatever HTML tags are designated as safe.
As HTML documents have a flat structure that mixes control statements, formatting, and content, any non-validated user input included in the resulting page without proper HTML encoding could lead to an injection attack.
A classic attack vector of this type of cyber attack is a site's search engine. If one searches for a word, the word is typically displayed verbatim on the result page to indicate what was searched for.
If the response does not escape or reject HTML control characters, a cross-site scripting flaw will ensue.
These attacks are typically delivered by phishing emails or a neutral website. The malicious URL points to a trusted site but contains the reflected XSS attack, and if the site is vulnerable to reflected attacks clicking the link will cause the victim's browser to execute the injected script.
Persistent (stored) XSS attacks
Persistent (or stored) XSS vulnerability is the more damaging variant of cross-site scripting.
It occurs when the data provided by the attacker is saved by the web server, and then permanently displayed on normal pages returned to other users in the course of regular browsing.
A famous example of this type of attack is called Samy. Samy was a cross-site scripting computer worm that propagated across the social networking site Myspace.
When a user viewed an infected profile, the payload would be replicated and planted on their own profile to continue the distribution of the worm.
Within 20 hours of its October 4, 2005 release over one million users had run the payload, making Samy the fastest-spreading worm of all time.
The worm itself was rather harmless, its payload would display "but most of all, samy is my hero" on the victim's profile and send its creator Samy Kamar a friend request.
This is a benign example. Persistent XSS vulnerabilities can represent significant cybersecurity risk when compared to reflected XSS vulnerabilities because, as Samy illustrates, the malicious script is rendered automatically, without the need to individually target victims or lure them to a website.
The method of injection can vary greatly, the attacker may not even need to directly interact with the web functionality itself to exploit a hole. Any data received by the web application (via email, system logs, IMs, etc) that can be controlled by an attacker could be potential attack vectors.
Self-XSS is a social engineering attack used to gain control of a victim's web account.
In a Self-XSS attack, the victim of the attack is coerced into running malicious code in their own web browser, thus exposing them to the attacker.
Today, Mozilla Firefox and Google Chrome have both introduced safeguards to warn users about Self-XSS attacks.
Mutated XSS (mXSS)
Mutated XSS happens when the attacker injects something that seems safe but is rewritten and modified by the user's browser while parsing the markup.
These attacks are hard to detect or sanitize within the application logic.
The difference between server-side and DOM-based cross-site scripting
Historically, XSS vulnerabilities were found in applications that performed all data processing on the server died.
This meant all user input was sent to the server and then sent back to the user as a web page, opening up the potential for persistent XSS attacks.
How to prevent XSS attacks
Preventing XSS attacks is a key component of web application security and one of the OWASP Top Ten.
That said, there is no single strategy for mitigating cross-site scripting, and different web applications require different levels of protection. A number of protective measures can be taken, including:
- Using modern frameworks that escape XSS by design, such as Ruby on Rails or React
- Learning the limitations of a framework's XSS protection and appropriately handle the exceptions
- Escaping untrusted HTTP requests
- Validating, filtering or sanitizing user-generated content
- Using a Content Security Policy (CSP) as a defense-in-depth control
- Avoiding HTML inputs, use other options
- Taking cookie security measures
- Setting WAF rules to block strange requests to the server
How UpGuard can help reduce web risks
Companies like Intercontinental Exchange, Taylor Fry, The New York Stock Exchange, IAG, First State Super, Akamai, Morningstar, and NASA use UpGuard's security ratings to protect their data, prevent data breaches and assess their security posture.
UpGuard Vendor Risk can minimize the amount of time your organization spends assessing related and third-party information security controls by automating vendor questionnaires and providing vendor questionnaire templates.
We can help you continuously monitor your vendors' external security controls and provide an unbiased security rating.
We base our ratings on the analysis of 70+ vectors including:
- Susceptibility to man-in-the-middle attacks
- Insecure SSL/TLS certificates
- SPF, DKIM and DMARC settings
- HTTP Strict Transport Security (HSTS)
- Email spoofing and phishing risk
- Malware susceptibility
- Unnecessary open administration, database, app, email and file sharing ports
- Exposure to known data breaches and data leaks
- Vulnerable software
- HTTP accessibility
- Secure cookie configuration
- Results of intelligent security questionnaires
We can also help you instantly benchmark your current and potential vendors against their industry, so you can see how they stack up.
For the assessment of your information security controls, UpGuard BreachSight can monitor your organization for 70+ security controls providing a simple, easy-to-understand cyber security rating and automatically detect leaked credentials and data exposures in S3 buckets, Rsync servers, GitHub repos and more.
You can read more about what our customers are saying on Gartner reviews.
If you'd like to see your organization's security rating, click here to request your free Cyber Security Rating.