

Cross-Site Scripting (XSS)

Author: Austin Harman
 

  

What is cross-site scripting (XSS)?

Cross-site scripting, commonly referred to as XSS, is a web security vulnerability that allows an attacker

to compromise how a user interacts with a vulnerable application. It allows an attacker to circumvent the

‘same-origin’ policy, which is designed to segregate different websites from each other. Typically, cross-

site scripting vulnerabilities will allow an attacker to act as a victim user which they then abuse to

perform actions or access data that the user should be able to do. This means that if the victim user has

elevated permissions as an administrator of the application, then the attacker might be able to gain

complete control over all of the application – including it’s sensitive data.
 

How does XSS work?

Cross-site scripting occurs when a vulnerable application or web site is manipulated so that malicious

scripts (JavaScript) is returned to users. Once that malicious script is executed in a user/victim’s browser,

the nefarious actor can fully compromise that user’s interaction with the application.

What are the types of XSS attacks?

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

Reflected Cross-Site Scripting: Malicious script comes from the HTTP request.

Stored Cross-Site Scripting: Malicious script comes from the database of the web application.

DOM-based Cross-Site Scripting: Malicious script comes from client-side code instead of server-

side code.

— Reflected XSS

Reflected XSS is the most common variety of cross-site scripting. It occurs when an application receives

data in a HTTP request and that request includes data within the immediate response in an insecure way.

Here is a simple example of a reflected XSS vulnerability:

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

The application doesn’t

correctly handle or process the input, so an attacker can easily construct an

attack like this:

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

<p>Status: <script>/* Scary stuff here... */</script></p>

If an unknowing user visits the URL constructed by the nefarious actor, then the attacker’s script will

execute in the victim’s browser. At that point, because the application doesn’t properly process the input,

the script can carry out any action that the user has the permissions to do. This could be used to retrieve

data that only the victim should have access to, but the malicious script will provide that info to the

attacker.

— Stored XSS

Stored XSS, which is commonly called persistent or second-order XSS, occurs when an application

receives data from an untrusted source and then actually includes that data within its HTTP responses in

an insecure way.

The information or data might be submitted to the application via HTTP requests. As an example, let’s say

that a forum lets users submit messages to other users.

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

If the application doesn’t perform any other processing of the user input, an attacker can easily send a

message that targets other users by submitting malicious payloads. For an example..

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

— DOM XSS

DOM XSS occurs when an application contains JavaScript on the client-side that processes data from an


untrusted source in an insecure way.

In the example below, an application uses JavaScript to read the input and then writes 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, then they can just as easily construct a malicious

input that causes their own script to execute:

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

Typically, the input field would be populated from part of the HTTP request, (such as a URL query string)

which would allow the attacker to deliver an attack using a malicious URL in the same way as reflected

XSS (which we discussed above).

What can XSS be used for?

A nefarious actor who leverages a cross-site scripting vulnerability might be able to accomplish a number

of different things:

Impersonate the user that unknowingly executed the attackers script.

Perform any actions that the victim is allowed to.

Access all data that the victim can access.

Compromise the victim’s login credentials.

Impact of XSS vulnerabilities

As with many vulnerabilities, the impact of cross-site scripting can vary in a number of ways. This is why

it’s important to perform penetration tests on web applications so that you can determine what the
business impact of any given vulnerability is.

The impact strongly relies on variables such as the type of data an application has, the permissions that


the victim has, and the general functionality of the application. If you reference the ‘What can XSS be

used for?” section above, you can imagine the impact if a banking application was to be vulnerable to XSS.

Conversely the impact may not be as severe if a website advertising a local party is vulnerable.

How to prevent XSS attacks

It’s difficult to cover all the different ways to prevent cross-site scripting vulnerabilities in a single article,

let alone a single paragraph. For a comprehensive review of preventing XSS, we’d recommend going

through the cheat sheet that OWASP put together. Below are some general rules to follow:

Education and awareness: Ensure that developers have knowledge of common security

vulnerabilities and risks found in web applications. Security should be baked into the software

development life cycle (SDLC) and OWASP vulnerabilities should be front of mind for developers.

Sanitize Input: When user input is received, you should filter as strictly as possible based on what

type of input is expected. Overall, you should never trust user input.

Content Security Policy: CSP can be used to define what domains are trusted to run executable

scripts. When correctly configured, this can theoretically mitigate XXS as an attack vector.

Share this post with your friends

  