Introduction

This may be obvious but XSS is one of my favourite vuleranbility types because of the depth and complexity. It all seems so super simple but when you really get down to the core of XSS there is a world of wonder to explore. Besides the different types of XSS ( Being reflected, stored and DOM - blind XSS is another form of stored XSS ) there are also a lot of different contexts which most people seem to glance over completely. Most courses and articles that cover XSS will only concern themselves with HTML injection but this is just a small part of what XSS is all about.

We will look at what it takes to look for all kinds of XSS attacks in all sorts of contexts but also at what we can do to stop this kind of attack.

What is XSS?

First we need to know why this vulnerability type occurs and we can state that this issue can arise wherever the developer takes user input and renders it onto the page without sanitizing that input. There are several ways to sanitise the input of which the safest but also most restrictive seems to be whitelist based filtering.

Whitelist based filtering is implemented by checking every single piece of user content and only allowing it if that user input is defined on a whitelist. As you can see this can be very cumbersome as we need to define every single input we want to allow which can give a lot of unforeseen issues.

For those reasons a blacklist based filtering system is often chosen where the input is filtered if all or part of it occurs on a blacklist. This is a lot less safe though because if the developer forgets just 1 value on the blacklist they might be opening themselves up to major attacks.

What is the impact?

The impact of XSS really depends on a couple of factors. We need to check which context we are in, what cookies have the httponly flag and if there is any data we can steal on the page. All of these are just a couple of factors that determine the impact but to be complete we should name all the factors that can improve the impact of an XSS that we can think off. Be warned though that this is based on the limited knowledge of one rat so it might be a bit lackluster.

What i do know though is that a simple alert() will not be enough to prove impact anymore and getting that popup is only half of the job. This is also where it really becomes important to know javascript on a useable level.

• Do the session cookies have httponly cookies? If you are a developer set these as they serve to protect cookies from the scripting context

• Can we steal data from the page? If you are a developer make sure that CSP is properly implemented on at least the pages that contain sensitive information. This is not an easy task as we might need to allow certain resources which might open us up to things like dangling markup injection.

• Can we execute sensitive JS functions? Remember that XSS can execute any JS function that is available to the current context so that means you might be able to execute a sensitive function such as DeleteAccount();

• Are we in an iframe or sandbox? This will limit any sort of data we can access and is usually pretty effictive against XSS if the seperation of data has been applied properly

• What context are we working in? After all if we are able to insert data into a hidden input field's attribute value it might not be as impactful as being able to insert a script tag on a page. This is because hidden input fields can't grab focus easily so they can't really trigger any JS handlers without user interaction.

• Can we simply steal any data without having to execute danling markup injection?

• Can we steal CSRF tokens and chain XSS into CSRF?

• If we have self-xss try to upgrade the severity by chaining it with a CSRF issue where the server does not check the CSRF token properly thus allowing you to insert your xss attack vector into someone else's account.

How to test for XSS

Passive method