What are types of Cross-Site Scripting (XSS) attacks?

We typically have 3 types of Cross-Site Scripting (XSS) attacks, this is outdated knowledge still circculating today.

Current Application Security and Penetration Testing knowledge has 5 distinct categories of XSS

The originals

Stored, DOM, and Reflected.

Where Stored XSS is simply described by one user entering the malicious attack into some sort of storage that the next user will load and the attack is performed.

DOM XSS uses HTML Elements directly, or some Pure JavaScript to manipulate the DOM.

Reflected XSS is typically everything else, even the newer 2 categories would usually get bundled into this category. For that reason this category is usually misunderstood. For the attack to be reflected    it must not stay within the same single trust boundary. To better understand trust boundaries you can do some research into 'Threat Modelling'. There is a hint in the XSS category 'Self XSS' below:

Segue into Self XSS, which is distinct from Reflected XSS because reflected does not exploit the Server-side trust in the user context where Self XSS purposefully exploits that trust. An example of Self XSS might include access to protected non-public resources the user usually has access too, but not the resources of other users outside the trust boundary. Self XSS is a risk for the user data being leaked to recipients that are not the intended user which is only possible when there is insufficient "Authorization" in place. The user is Authenticated and the attacker takes advantage of that trust relationship, but due to the user data access being trusted in perpetuity, without a challenge-response check to ensure the user is Authorized to access the data, the attacker is able to leverage the trust and assume the user identity to get unfettered access to that users data.

Many web scrapers and spiders use this technique to take all data from your site, these are typically called bots but they are actually malicious actors leveraging the Authorization flaw in your archetecture. Bots are useless against any system that implements basic Authorization challenge-response checking, period. If you have a bot issue, you have an Authorization issue and user trust is the attack vector the bot uses, and many malicious actors may also leverage that trust to perform other Self XSS attacks on you.

We are at the final category: Mutated XSS which takes advantage of device trust. Therefor there are 2 types of XSS that exploit the trust that a server has established! This is rarely discussed..

Mutated XSS is generally seen in an enterprise environment where devices are considered 'internal assets' even when they are a laptop being taken great distances from the local / private networks that would legitimately be considered 'internal' for that asset. Sometimes the device has a VPN installed and they are often not active or drop out. There is also the active VPN and IPv6 leak problem that makes these devices not internal even when they are considered to be communicating internally by classically trained I.T. administrators.

If an XSS attack leverages the device trust relationship with a network considered 'internal' we are looking at Mutated XSS and not Reflected XSS because the same attack that leverages the Active Directory on 1 network via the trusted device, will have zero effect on another device. So Reflected XSS is an insufficient description, Mutated XSS and specifically the device trust categorisation makes the attack very clear how it effects you.

Story time

I was recently in a discussion with a penetration tester, and a security manager type, during that discussion the 3 types Reflected, DOM, and Stored were being discussed.

Stored and DOM are pretty much solved problems the manager said. Just use HTTP headers, modern Javascript frameworks, and input validation. The Pentester disagreed but they moved onto Reflected XSS and agreed that it remains the most common XSS attack vector so they looked to me as the Application Security Lead to see if I had any suggestions.

I confirmed that a lot of XSS that are DOM XSS use pure Javascript, no DOM elements typically get used any more but that is not the reason to ignore checking for DOM XSS in our app because browser extensions and old websites are still using this technique. They disagree but the decision was to reduce the findings to a Low risk due to a risk likelihood calculation. Fair.

We quickly moved on to Reflected XSS and looked at some code samples - I immediately noticed that to be successful it takes advantage of trust the server has in the user or device for both samples. If they occurred via something like Facebook, Reddit, ect. that are all public and have no inherent trust, they'd not be considered Reflected XSS that would result in any Threat to those sites but for us they pose a risk because of our flawed trust boundaries.

They looked puzzled. I asked; "Have you heard of mXSS or sXSS?"

They hadn't and below is a paraphrased explanation I gave at the time:

Self XSS takes advantage in the trust the server has with the user session, if a malicious payload executes in the user context all sorts of user data can be gained, including active social media, email, and banking sessions. Reflected, DOM, and Stored fit this category too, they can exploit user trust but unless they actually exploit that trust they are not considered Self XSS. The distinction is that Self XSS has no other effect when the user trust is not present where the other 3 classic XSS categories may still pose a threat in the absence of user trust.

After this explanation Mutated XSS was easy to comprehend. Given it takes advantage of device trust and the security manager is well aware of the assets that could be targeted, there was not much I needed to clarify. But the penetration tester remarked they disagree and would like to discuss this later, they never contacted me about this again.

Try telling this to a so-called "real" penetration tester, they'll get confused by the trust concepts. While a security manager understand the trust concepts, they tend to be "formally" educated and not "experience" educated so they think the 3 types are only DOM, Stored, and Reflected because that is what they were taught.

Conclusion

There are really 3 types of XSS that we have in reality and they are not Stored, Reflected, DOM. They are granular categories below the 3 that are the real XSS categories:

1) XSS that exploits the user trust relationship with the targeted server
2) XSS that exploits device trust with the targeted server
3) XSS that pose a risk when there is no trust relationship exploited

If you break these 3 down into the 5 known subcategories Stored, DOM, Reflected, Self, Mutated - we may have more distinct subcategories in future too but the main 3 categories may never change.