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.
Vulnerable web applications that are commonly used for cross-site scripting attacks are forums, message boards, and web pages that allow comments. If user input is not sanitized, XSS attacks are possible in VBScript, ActiveX, Flash, JavaScript, and CSS.
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?
While XSS vulnerabilities may be perceived as less dangerous than say SQL injection vulnerabilities, the consequences of XSS attacks, especially stored XSS attacks that rely on JavaScript can be very dangerous because:
- JavaScript can access all objects that a web page has access to, this can include a user's cookies with document.cookie, which can allow attackers to gain access to a session cookies if they are not adequately protected. If an attacker can access a user's session, they can impersonate the user, perform actions on behalf of the user, and gain access to sensitive data.
- JavaScript can read the browser's domain and make modifications to it, enabling website defacement and exposure of sensitive information.
- JavaScript can use the XMLHttpRequest object to send HTTP requests
- JavaScript in modern browsers can use HTML5 APIs, which can be used to gain access to the user's geolocation, webcam, microphone, and even files on their computer. While most of these APIs require opt-in, attackers can use social engineering to coerce victims into approving their requests.
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
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.
In the past, a very similar attack took place which tricked users into pasting malicious JavaScript into their address bar. Once browser vendors fixed this vulnerability, attackers started using Self-XSS in its current form.
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.
However, the demand for improved user experience resulted in developers moving the majority of presentation logic (e.g. JavaScript code) to the client-side, pulling data on-demand from the server using AJAX.
As the JavaScript code was also processing input and rendering it on the web page, it opened up reflected XSS attacks or DOM-based XSS. As we touch on above, this malicious content does not touch the web server and rather is being reflected by the JavaScript code solely on the client-side.
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
Read our full guide on the OWASP Top Ten for more information.
How UpGuard Can Help Reduce Web Risks
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
- Vulnerabilities
- 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 vendor risk assessment 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.
The major difference between UpGuard and other security ratings vendors is that there is very public evidence of our expertise in preventing data breaches and data leaks.
Our expertise has been featured in the likes of The New York Times, The Wall Street Journal, Bloomberg, The Washington Post, Forbes, Reuters, and TechCrunch.
You can read more about what our customers are saying on Gartner reviews.
