Notes on Cross-Site Scripting (XSS)

Overview

Cheat Sheet

https://portswigger.net/web-security/cross-site-scripting/cheat-sheet

Types of Cross Site Scripting

There are three main types of XSS attacks. These are:

Reflected XSS - the script comes from the current HTTP request
Stored XSS - the script comes from the website's database
DOM-based XSS - the script is injected client-side rather than server-side

Notes

Reflected XSS

Basic Reflected XSS Attack

An example of a reflected XSS attack would be a page that accepts input from a URL parameter, and dynamically inserts it in the page without any additional processing.

An example might be a "message" parameter in a URL that is used to display a greeting on a page.

https://insecure-website.com/status?message=All+is+well.

This could be attacked like so:

https://insecure-website.com/status?message=<script>/*+Bad+stuff+here...+*/</script>

For the purposes of testing, can just input something simple like this:

<script>alert(1)</script>

Stored XSS

Basic Stored XSS Attack

An example of a stored XSS vulnerability would be a message board application. Users can submit messages that will be stored in a database, and those messages will be retrieved and displayed for other users. If the application does not do any additional processing, a malicious user could submit a message with the contents

<script>/* Bad stuff here... */</script>

and that Javascript would be executed in the browser of anyone viewing that message.

DOM XSS

Basic DOM-Based XSS Attack

DOM-based XSS occurs when an application contains client-side Javascript code that is processing untrusted data in an unsafe way.

An example of this would be an application with Javascript code that reads a value from an input field, and uses that value without processing it to populate other DOM elements on the page.

An example might be:

var search = document.getElementById('search').value;
var results = document.getElementById('results');
results.innerHTML = 'You searched for: ' + search;

The attacker must be able to control the input field's value. If they do, they can provide a value that consists of HTML tags that will execute malicious Javascript code.

This attack usually takes the form of an input field whose value comes from the URL. Then the attacker can deliver the attack by getting the victim to visit the URL - similar to reflected XSS.

What Can Attackers Do

XSS attacks allow the attacker access to that page/session/tab of the browser. They can see and control everything happening on that page. That means they can manipulate the contents of the page, deface it, create a fake login box that captures credentials, and read any data displayed on the page, even if it is private, protected data.

XSS has high impact in web applications dealing with sensitive information - banking, finance, healthcare, other records.

XSS also has high impact if the user that is compromised has elevated privileges, since the attacker will be able to take control of the application to compromise other users and their data.

Exploiting XSS

https://portswigger.net/web-security/cross-site-scripting/exploiting

Three ways that an XSS vulnerability can be exploited:

Stealing cookies (send the victim's cookies to your own domain, then manually inject the cookies into your browser and impersonate the victim)
Capturing passwords (e.g., from password managers auto-filling the password field)
Performing CSRF (allows attacker to perform actions as the victim - such as sending a message, transferring money, or changing the primary account email)

Stealing Cookies with XSS

https://portswigger.net/web-security/cross-site-scripting/exploiting/lab-stealing-cookies

Finding XSS Vulnerabilities

To find XSS vulnerabilities in an automated way, the Burp Suite paid edition has a web vulnerability scanner. https://portswigger.net/burp/vulnerability-scanner

If you're using the community edition, you'll have to do it all manually.

Finding Reflected XSS Vulnerabilities

Finding reflected XSS vulnerabilities manually is a two-step process: first, submit a simple and unique input (like "pickle") into every entry point in the application, and identify where the unique input is returned in HTTP responses. Second, test each location individually to find out if it can be used to execute arbitrary Javascript code.

Finding DOM XSS Vulnerabilities

Finding DOM XSS vulnerabilities follows the same two-step process: first, submitting a unique string in every entry point of the application, and identifying where this unique string shows up in the DOM document in the browser. Second, testing each location to see if it is vulnerable to a DOM XSS exploit.

(This is a difficult task, it is time-consuming to review JS code to find non-URL-based input or non-HTML-based sinks. Burp Suite Professional has static/dynamic tools to take care of this.)

Prevention

Filter input on arrival (as strictly as possible, as soon as possible)
Encode data on output (to prevent it from being interpreted as active content; can use HTML, URL, JS, and/or CSS encoding)
Use appropriate response headers (use Content-Type and X-Content-Type-Options for responses that should not contain HTML or Javascript, to ensure browser interprets correctly)
Content security policy (last line of defense to reduce severity of XSS vulnerabilities)

XSS

From charlesreid1

Contents