XSS VRT Items

[aidanstansfield]

trafficstars

Hi all,

I wanted to bring up a few issues myself and some other ASE's have been seeing with the current XSS VRT items. In particular, there is some confusion/inconsistencies that arise with the stored variants of XSS.

For example, an alert(1) payload is a P3 when the XSS is reflected, and P4 when it is stored. Why should this be the case? i.e. why should making a victim visit https://website/page?param=alert(1) be a higher priority issue than making a victim visit https://website/page where the same alert(1) payload is stored in the page? If anything, making a victim visit https://website/page is less suspicious since there is no visible payload within the URL.

As another example, if the attacker can store an XSS payload within the page (P4), then there is a high probability they could change their script injection to an iframe injection, which is a P3. This means that if a researcher finds a stored XSS and they can't be bothered to find a way to elevate their privileges with it, they can just change it to a simple iframe injection and receive the same rewards (I have seen this occur).

As another example, the Stored > CSRF/URL-Based (P3) VRT item is intended to be used in a few situations. For URL-Based, it's to be used where the XSS Requires Attacker to Provide Payload URL to Victim according to #123. This means if the attacker has a stored XSS that doesn't elevate privileges but fires when the victim visits https://website/page for example, then it's unclear whether this should be classified as the P3 or P4.

The Stored CSRF-Based entry is for situations like stored self-XSS + login CSRF also according to #123. This seems to be commonly confused with P5 Self Reflected XSS via a post request, since researcher's think this means any XSS achieved by CSRF.

I'm not sure what the best method of resolution here is and I'm not sure what priority high/low impact should be given, but an example I can think of would be the following:

XSS

• P2/P3: High impact (e.g. privilege elevation, account takeover)
• P3/P4: Low impact (e.g. any alert payload)
• P5: Self XSS

You could chose to implement these for both reflected & stored if you want a way to differentiate between the two, or you could consolidate them into one for simplicity.

I wanted to bring this up for discussion, as I (and some other) ASE's have run into various issues regarding these VRT items (particularly stored XSS).

[aidanstansfield]

I just wanted to point out that the P4 variant (Cross-Site Scripting (XSS) > Stored > Privileged User to No Privilege Elevation) is for when the stored XSS is made by a privileged user (e.g. an application where you have your own organisation within the application and can control the users within your organisation). For situations where there is a global user base and anyone can sign up (e.g. a public forum), then the P2 variant (Cross-Site Scripting (XSS) > Stored > Non-Privileged User to Anyone) still applies.

[plr0man]

While alert(1) is not a good way to demonstrate PoC and could really be P5 across the board, let me not dig into this here, to keep the focus on the differences between stored and rXSS. Stored XSS is very much related to who can inject the payload. To give you an example, if I was an admin of a website and could inject javascript into one of its pages, that would be a P4->Privileged User to No Privilege Elevation. This is due to the fact that only a select group of privileged individuals can perform the injection and they could only attack each other. I can see how some organizations could view that as accepted risk. On the other hand if on the same website there was an rXSS, this would mean that anyone can attack anyone. So while the payload delivery is not as seamless, a regular user could takeover admin accounts and the overall severity would be much higher than in the previous example.

The iframe injection and URL based examples should be governed by the same principle at the ASE's discretion. I can see the potential for improvements here,

I am not sure I understand the CSRF based stored XSS question. For example, if I can inject a payload into your account setting's via CSRF, then that would fall under that P3 entry. This is due to the fact that I need to make you visit my CSRF form as a prerequisite of the attack.

[TimmyBugcrowd]

I agree with plr0man's comment here. The categorization is based on who does the injection. An XSS from a non-privileged user affecting everyone is P2. The other way around is P4.

Also, having the victim visit a URL which then results in stored XSS is P3 due to that pre-requisite.

I'm closing this issue based on this and due to inactivity. If you have any other arguments that we can discuss, feel free to open a new issue.

-Timmy