XSS

https://portswigger.net/web-security

What is Cross-Site Scripting (XSS)?

XSS is a web security vulnerability, which allowed an attacker to comprimize the inheractions that users have with a vulnerable application. Attackes are able to inject malicious client-side scripts into trusted websites. Instead of attackig the victim directly, the attacker exploits flwas in web applications that fail to properly validate or sanitize user input, causing the victim’s browser to execute the malicious code as if it were from the trusted site.

All XSS labs: https://portswigger.net/web-security/all-labs#cross-site-scripting

XSS is usually used using JavaScript. You can confirm XSS vulnerabilities using the JS altert() functions for this purpose: It is simple, fast, harmless and hard to miss. PortSwigger suggests that many of the LABs can be solved invoking altert() However, there is a problem if you use Chrome. From version 92 onward, chrome simply blocked the altert() function. They suggest using the print() function.

What are the types of XSS attacks?

There are three main types:

• Reflected XSS, where the malicious script comes from the current HTTP request
• Stored XSS, where the malicious script coems from the website’s database (persitent)
• DOM-based XSS, where the vulnerability exists in client-side code rather than server-side code.

Reflected cross-site scripting

Reflected XSS is the simplest variety of XSS. It arises when an application receives data in an HTTP request and includes that data within the immediate response in an unsafe way.

Simpel example of a relected XSS vulnerability:

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

The application does not perform any other processing of the data, so an attacker can easily construct an attack like this:

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

If the users vitis the URl consturcted by the attacker, then the attacker’s script executes in the user’s brower, in the contect of that user’s session with the application. At that point, the script can carry out any action, and retreive any data, to which the user has access.

Stored cross-site scripting

Stored XSS arises when an application receives data from an untrusted source and includes that data within its later HTTP responses in an unsafe way. The data in question might be submitted to the application via HTTP request; for example, comments on a blog post, usernames in a chatroom, or contect details on a customer order. In other cases, the data might arrive from other untrusted sources; for example, a webmail application displaying messages recevied over SMTP, a marketing application displaying social media posts, or a network monitoring application displaying packet adata from network traffic. Basically, the payload is stored and gets executed by the user when accessing the website/requesting HTTP

Here is a simple example fo a stored XSS vulnerability. Think of a message board applciation which lets users submit messages, which are displayed to other users:

<p>Hello, this is my message!</p>

We assume the application does not perform any other processing of the data, so an attacker can easily send a message that attacks other users:

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

DOM-based cross-site scripting

DOM-based XSS (Document Object Model XSS) arises when an application contains some client-side JavaScript that processes data from an untrusted source in an unsafe way, usuallly by writing the dtaa back to the DOM (Document Object Model). In the following example, an application uses some JavaScript to read the value from an input field and write that value to an element within the HTML:

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

If the attacker can control the value of the input field, they can easily contrust a malicious value that causes their own script to execute:

You searched for: <img src=1 onerror='/* Bad stuff here... */'>

In a typical case, the input field would be populated from the part of the HTTP request, such as a URL query string parameter, allowing the attacker to deliver using a malicious URL, in the same manner as reflected XSS.

What can XSS be used for?

An attacker who exploits a XSS vulnerability is typically able to:

• Impersonate or masquerade as the victim user.
• Carry out any action that the user is able to perform
• Read any data that the user is able to access
• Caputre the user’s login credentials-
• Perform virtual defacement of the web site
• Inject trojan functionality into the web site

How to find and test for XSS vulnerabilities

Manually testing for reflected and stored XSS normally involves submitting some simple unquite input into every point in the application, indentifying every locatio where the submitted input is returned in HTTP responses, and testing each location individually to determine whether suitably crafted input can be used to execute arbitrary JS. In this was, you can determine the context in which the XSS occurs and select a suitable payload to exploit it.

Cheat Sheet

This cross-site scripting (XSS) cheat sheet contains many vectors that can help you bypass WAFs and filters. You can select vectors by the event, tag or browser and a proof of concept is included for every vector. https://portswigger.net/web-security/cross-site-scripting/cheat-sheet