CVSS3 score for XSS leading to account takeover

Question

Let's say there is a XSS vulnerability in a web application. The XSS allows an attacker to hijack the user's session. Within the session, the attacker can view/modify the user's credit card and billing information, and even make a purchase using the user's credit card. This has a critical impact to the attacked user(s), however, CVSS3 only seems to take into consideration the impact to the whole web application (?).

Since the XSS is easy to reproduce, the attacker could run this attack on many users, so the question is:

According to the CVSS3 specs (see the tables below), which of the following options suits best (if any):

Option 1 (CVSS 6.1)

• Scope: Changed
• User interaction: Required
• Attack complexity: Low
• Confidentiality: Low
• Integrity: Low

Option 2 (CVSS 9.3)

• Scope: Changed
• User interation: Required
• Attack complexity: Low
• Confidentiality: High
• Integrity: High

Option 3 (CVSS 8.0)

• Scope: Changed
• User interation: Required
• Attack complexity: High
• Confidentiality: High
• Integrity: High

I was advised to choose the option 3 based on the following criteria:

• Achieving a High impact for Confidentiality and Integrity would require to compromise most or all user accounts in the web application.
• Doing so, would require the attacker to make a considerable effort by exploiting the XSS at a large scale (hence Attack complexity: High).

Do you agree with this criteria? If not, which option would you choose?

Your opinions are very much appreciated.

---

Appendix

Confidentiality

Value	Description
High (H)	There is a total loss of confidentiality, resulting in all resources within the impacted component being divulged to the attacker. Alternatively, access to only some restricted information is obtained, but the disclosed information presents a direct, serious impact. For example, an attacker steals the administrator's password, or private encryption keys of a web server.
Low (L)	There is some loss of confidentiality. Access to some restricted information is obtained, but the attacker does not have control over what information is obtained, or the amount or kind of loss is limited. The information disclosure does not cause a direct, serious loss to the impacted component.

Integrity

Value	Description
High (H)	There is a total loss of integrity, or a complete loss of protection. For example, the attacker is able to modify any/all files protected by the impacted component. Alternatively, only some files can be modified, but malicious modification would present a direct, serious consequence to the impacted component.
Low (L)	Modification of data is possible, but the attacker does not have control over the consequence of a modification, or the amount of modification is limited. The data modification does not have a direct, serious impact on the impacted component.

Answer 1

This is not an easy question. IMHO CVSS moved on from a generic, catch-all evaluation of all XSS (it used to be more or less rXSS[] + post-auth pXSS[] = Medium, pre-auth pXSS = High). The examples make it clear that analyzing the specific impact on the application is important.

But that hasn't really caught on (in my experience). People are hesitant to give anything higher than High to XSS (possibly with the exception of bxss in critical applications) and for the most part stick to the old-school thinking of pre-auth pXSS = High, everything else = Medium. If CVSS is applied as - imho - it should be, you often get scores that feel too high for XSS.

---

That being said, let's look at the different metrics.

Scope: Changed

That's standard for XSS and what the spec demands (scope change browser -> web app). I have seen cases where it is evaluated as Unchanged unless a different web app than the vulnerable one is affected. I think there's a certain rational to that, but it's not according to the spec.

User interaction: Required

This is also standard. I think there's an argument to be had that for persistent XSS, UI is none if the payload is in an regularly-visited functionality of the webpage (eg the front page). But it's a non-standard opinion.

Attack complexity: Low / High

Low is standard. Exploiting the issue at scale (eg sending rXSS links to a lot of users, posting a pXSS payload in a lot of places) isn't captured by AC.

CIA

This is the heart of the issue. Based on the CVSS XSS example we can see that indirect impact / the impact on the app in question matters.

But in my experience, rXSS is generally evaluated CI:Low since only one user can be attacked at a time (example for rXSS in the CVSS v4 spec with the standard 6.1 CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N).

Now, imho there's an argument for High to be made. The CVSS spec talks about a total loss of confidentiality (we generally don't have that when attacking one user) or the disclosed information presents a direct, serious impact. Arguably, PII, private messages, credit cards, etc would qualify.

And that's just considering attacking "normal" users. What if we attack an admin? Eg in wordpress, that can generally lead to RCE. Which would give us 9.6 crit for a rXSS.

What about pXSS? Well, in practice, it's also often set as CI:Low (see eg here). That's clearly against the spec & examples. But if you don't do it, you quickly end up with a crit for pre-auth persistent XSS (if it's account takeover, which most XSS are). Is that right? Arguably it is. But it doesn't feel right (imho mostly because people underestimate XSS).

Essentially, I think most CVSS calculations try to fudge the value so that they get the familiar pre-auth pXSS = High, everything else = Medium. That's generally done in a number of ways:

• via UI: pXSS=None, rXSS=R. CI:Low
• via scope:unchanged: pre-auth pXSS: CI:High, otherwise Low
• by fudging CIA: rXSS LowLowNone, post-auth pXSS HighLowNone, pre-auth pXSS HighHighNone (or HighLowNone, doesn't matter)
• via AC (see eg this rXSS, which uses AC to fudge a crit to High).

jenkins is an interesting example. They set Scope:Unchanged, but - correctly - CIA:High because of the impact on the application (no surprises on AC,PR,UI). So they end up with High for post-auth pXSS & rXSS and (presumably) also High for pre-auth pXSS. If they were to set Scope:Changed (as the CVSS spec demands), all XSS would be crits.

--

Problems:

Above is the theory and my experience with and interpretation of the CVSS spec and examples (essentially, I think most people fudge it so it matches their gut feeling; which often under-estimates XSS; it would probably be helpful to think: "if this were a blind XSS that fired, would I still give it this score?" because people don't underestimate bXSS the same way).

We can see that no matter what we do we are running into a lot of problems with the scores we get and what we feel like a vulnerability should be.

We have eg seen that when considering the impact on the application, we can end up with a crit rXSS. Which doesn't really feel right (even though real-world impact might actually support that evaluation). We can also get situations where an rXSS isn't higher than a pre-auth pXSS which also seems odd.

---

What do I think? I like to stay close to the spec (while still fudging a bit if necessary). These are some examples how I'd rate things:

• rXSS with access to highly sensitive info / account takeover: High 8.2 CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:L/A:N.
• regular rXSS: Medium 6.1 CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N
• pre-auth pXSS, easily used to attack admin and/or any number of users & with access to sensitive data (read/write): Crit 9.3 CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:N
• pre-auth pXSS, attacking regular user, with semi-sensitive data: High 8.2 CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:L/A:N
• post-auth pXSS[**]: pretty much as above, but PR:Low

As you seem to be asking for bug bounty purposes, I can also say that this will for the most part not get through (especially if you find more than one XSS issue). IMHO it's according to spec (mostly), but rXSS and post-auth pXSS will be downgraded to Medium (even if you add an ATO POC). It's not fair, but that's how it is.

---

CVSS 4.0 to the rescue?

CVSS 4.0 looks interesting and like it might solve some problems:

• User interaction is separated into Active (rXSS, pXSS where you need to click a link, etc) and Passive (regular pXSS). This not only helps to differentiate rXSS and pXSS, but even different pXSS vulnerabilities.
• no more Scope, instead Vulnerable System & Subsequent System. It's still unclear how this will be handled in practice. This imho makes more sense than the Scope:Changed (browser -> web app) of CVSS 3.

But if you play around with the calculator, you will notice that you still don't get XSS scores that feel right. CVSS tries to cover a lot of different vulnerabilities (not just in web apps) & imho has real difficulties capturing XSS impact (which is disappointing, considering how common they are; I wish the CVSS 4 spec would add a lot more examples for common XSS scenarios).

[*] pXSS = persistent/stored XSS

rXSS = reflected XSS

[**] post-auth = requiring privileges (self-registration would eg be pre-auth; an example for post-auth is an app without registration where the account needs to be created by an admin or a low-priv user in an organization/tenant)

Answer 2

CVSS3 only takes into consideration the impact to the whole web application, and not just to a single user.

Is that so? Admittedly, it's been some time since I read the full CVSS specs and I could not find any part of the specs that support your interpretation after skimming the relevant sections. Please feel free to quote the parts you are referencing. Based on my interpretation of the definition of Confidentiality, I'd argue to the contrary:

2.3.1. Confidentiality (C)

This metric measures the impact to the confidentiality of the information resources managed by a software component due to a successfully exploited vulnerability. Confidentiality refers to limiting information access and disclosure to only authorized users, as well as preventing access by, or disclosure to, unauthorized ones.

Let's break this down:

the confidentiality of the information resources managed by a software component

I.e., the credit card number, credit card owner, and CVC.

limiting information access and disclosure to only authorized users

I.e. only the user who is the credit card owner as well as payment providers should have access to (some of) this CC data.

And to extend this by the definition of "High (H)":

Alternatively, access to only some restricted information is obtained, but the disclosed information presents a direct, serious impact.

This fits your scenario. Some users are affected, and the impact can be direct and serious.

In my interpretation, FIRST does not limit the loss of confidentiality to the entire web application. And in my opinion, such a limit would not make any sense in real world scenarios. If you can gain access to highly sensitive and critical user data due to a flaw in the web application itself and not via user error (e.g. Password123!), it's valid to raise this as a critical issue.

CVSS is never an absolute science. In practice, it's a good indicator of the severity of a finding, which must be adjusted according to your professional experience and opinion.

Personally, I'd report this vulnerability to my client along the lines of Option 2 based on your scenario. This is also in line with the experience I have from working with large international banking clients. If such a flaw were discovered, this would be a Code Red situation and addressed immediately.

---

PS: Such a vulnerability would also affect adjacent areas, i.e. PCI DSS compliance. But if you store the CVV/CVC you probably won't keep your PCI DSS certificate for long anyway, see PCI DSS v4.0 Requirement 3.3 😄

3.3 Sensitive authentication data (SAD) is not stored after authorization.

Defined Approach Requirements

3.3.1 SAD is not retained after authorization, even if encrypted. All sensitive authentication data received is rendered unrecoverable upon completion of the authorization process.

Definition of SAD from Appendix G:

Term	Definition
Sensitive Authentication Data (SAD)	Security-related information used to authenticate cardholders and/or authorize payment card transactions. This information includes, but is not limited to, card validation verification codes/values, full track data (from magnetic stripe or equivalent on a chip), PINs, and PIN blocks.