XSS Admin -> everyone is rated too high

[jcran]

XSS (admin -> anyone why is this a p3 vs a p4? If you already have admin…

- https://twitter.com/jcran/status/999693045682454528

[ryancblack]

@jcran

We try to articulate role-based context in the brief as pertains to specific applications. "Admin" can certainly mean different levels of privilege so the focus is typically on the level of risk against higher privilege users or a broader set of users.

This may be an opportunity for thoughtful and limited additional granularity in variants however. If it were approached this way what options might you suggest?

[jcran]

Thanks for the thoughtful response. Not seeing a simple solution for the general case, but you might think about whether additional privs could be obtained through the exploitation of the flaw, and if so, then it should be rated higher. I suspect that most "admin" -> "user" cases don't really add any additional privs to the attacker.

[plr0man]

I suspect that most "admin" -> "user" cases don't really add any additional privs to the attacker.

Most applications in my experience offer multiple levels of users, from high priv admin to some type of manager and then regular low priv user. Sometimes it really gets complicated when you add different types of permissions. I would break the risk matrix down this way (not an actual entry proposal):

P3 - XSS to Vertical Privilege (e.g. some type of mid priv admin/manager vs high priv admin) P4/P3 - XSS to Horizontal Privilege Only (e.g. evil admin vs other admins or vs regular users if there's no absolute control over them) P5 - XSS to No Privilege (e.g. originating from super admin)

Now if we consider that bug bounties don't focus on testing super admins, we are left with the P4/P3 and P3 options. The logic behind the current P3 baseline as I see it is that "admins" are users and attacking others will benefit them in most cases, but the prerequisite of being some sort of higher privileged user merits a baseline rating that is a notch lower than the regular P2.

[jcran]

Thanks for the thoughtful response @plr0man. Agree with your thinking. Impact (privs gained) matters, not the roles themselves, and perhaps this should be re-worded around privs. whether vertical and horizonal are split out is purely a granularity decision, and i don't have strong feelings about it other than agreeing vertical > horizontal in most cases.

[jcran]

A bit more color around what prompted this. A submission was received that required admin-level privs to create/enter the script, but only regular user privs to land. So in that case, no additional privileges were gained, other than the ability to perform actions as that user, but the admin already had the ability to do everything the user could do and more. It was unclear if this would ever be truly useful to an attacker in practice. P4 was the prevailing thinking.

[plr0man]

Looks like we're all on the same page. Awaiting entry name proposal if anyone wants to approach it.

[plr0man]

Proposed solution: :p2: – Cross-Site Scripting (XSS) > Stored > Non-Privileged User to Anyone :p3: – Cross-Site Scripting (XSS) > Stored > Privileged User to Privilege Elevation :p4: – Cross-Site Scripting (XSS) > Stored > Privileged User to No Privilege Elevation :p3: – Cross-Site Scripting (XSS) > Stored > CSRF/URL-Based :p5: – Cross-Site Scripting (XSS) > Stored > Self Current classification for comparison: :p2: – Cross-Site Scripting (XSS) > Stored > Non-Admin to Anyone :p3: – Cross-Site Scripting (XSS) > Stored > Admin to Anyone :p3: – Cross-Site Scripting (XSS) > Stored > CSRF/URL-Based :p5: – Cross-Site Scripting (XSS) > Stored > Self

[truemongo]

Unless you are going to require a POC that shows actual privilege elevation (by leveraging the XSS), I'd suggest "Privileged User to Higher Privilege User", etc., or something more along those lines.

[plr0man]

That's a good suggestion @truemongo. What would you see as an alternative for :p4: – Cross-Site Scripting (XSS) > Stored > Privileged User to No Privilege Elevation ?

[eraymitrani]

What is the classification if the platform is something like a github organization where an admin's xss payload can steal non priv user sessions. You're basically stealing their accounts, even thought you are not gaining priv within the application context but you can do more things with the non-admin accounts.

[bayotop]

@eraymitrani In case we talk about an XSS on github.com, I'd say it's somewhere between Non-Privileged User to Anyone (P2) and Privileged User to Privilege Elevation (P3). As an organization admin you aren't really privileged in GH's context, but you can still target only a limited subset of GH users. I'd say P2, though. In case it's self-hosted on an isolated domain -- solely for one organization -- it's Privileged User to No Privilege Elevation (P4).

[plr0man]

Thanks for everyone's contribution. If there are not more comments in regards to the other option as discussed above:

That's a good suggestion @truemongo. What would you see as an alternative for :p4: – Cross-Site Scripting (XSS) > Stored > Privileged User to No Privilege Elevation ?

we'll move forward with the originally proposed solution.

[ghost]

@plr0man Sorry to post a comment so late, but talking about this issue with other researchers, I think there is a general feeling that it is a really bad idea to include additional classifications for an issue that involves an extremely small number of reports. The downsides (causing confusion and the potential for misclassification) are greater than any possible benefit.

The general policy should be applied here: The researcher needs to demonstrate impact. If the impact is negligible or non-existent, the report should be regarded as P5.

In response to the report that prompted this discussion:

A submission was received that required admin-level privs to create/enter the script, but only regular user privs to land. So in that case, no additional privileges were gained, other than the ability to perform actions as that user, but the admin already had the ability to do everything the user could do and more.

If the attacker is not able to perform a malicious action against their users using this XSS, then the risk is zero. Assuming that's correct I believe this report should have been marked as P5.

[plr0man]

@rsmith31415 current stored XSS classification although very simplified is already broken down by who can inject the payload and who can be affected by it. In this case we found it to be the best methodology that helps us stay consistent across all of our programs and set clear expectations for the researchers. We try to design our taxonomy so we rarely have to downgrade the baseline severity ratings, and at the same time we do upgrade based on context when appropriate and possible. Current stored XSS variants don't really allow us to follow this rule. For instance :p3: – Cross-Site Scripting (XSS) > Stored > Admin to Anyone as in the example that you provided would have to be downgraded to P5. I would argue that such scenarios are common enough to be formally addressed. That being said I don't think it is a question of "if" but "how" at this point, but do know that we appreciate you sharing your perspective.

[ghost]

@plr0man Thank you for your response.

I think we are talking about two different things:

1 - Are there XSS reports in which the attacker is not able to get anything valuable from the victim? Yes. What is the percentage of such cases? Based on personal experience and conversations with other researchers, this is extremely rare. Most of the time, the researcher needs to be pushed to demonstrate impact. If this percentage is not large enough to be measurable, then it is probably not sufficiently important to merit a change in the VRT

2 - If the design of the VRT discourages downgrades, that's great, but this should be a side-effect of having categories that are clear and easy to use. There will always be edge cases that for some reason or another, require a downgrade and I don't think that is a problem.

There is always a tendency to add more rules (in complexity or number) to cover as many scenarios as possible, but this involves the risk of "overfitting". I would suggest keeping categories that are generally applicable to 98% of the cases, and use judgment to manage the 2%.

[plr0man]

This proposed change is supposed to give us a more accurate risk assessment matrix as current entries are oversimplified and inaccurate given the complexity of potential attack scenarios. Breaking down a P3 into one P3 and one P4 variant is just a natural process for the VRT where we see the need for it.

In your fist point @rsmith31415 you are in fact describing an edge case that is not being addressed by those variants, we are not adding such P5 entry here. At the same time with this proposed change it would be much more reasonable to occasionally downgrade the newly proposed P4 (instead of current P3) to P5 if there's in fact no risk.

I believe that the logic behind the proposed baselines is pretty solid, but as it is sometimes the case it is not straightforward to grasp it in a short name.

[eraymitrani]

If there is going to be cases anywhere from P5 to P2 potentially it might make more sense to treat XSS like IDOR or CSRF in the VRT where the impact is determined by the program.

I think that would be welcome by most programs but could introduce some unintended inconsistencies across programs that frustrate researchers. I still think it is something you can consider.

[plr0man]

That's a good point @eraymitrani and the reason we don't have XSS or many other entries for that matter classified as "Varies" is because we try not to do that when we have the option not to. Having baseline severity ratings is the essential feature of the VRT and as long as there is a concise way to classify issues we strive to do that.

[ghost]

@plr0man The edge case I was describing is the issue that prompted this discussion in the first place. I suppose it needs to be included in a category (I thought maybe Privileged User to No Privilege Elevation), but it is not even clear if that's the case because the proposed categories are so subjective and subject to interpretation that are likely to cause endless discussion between triagers and researchers.

On the other hand, if the current proposals do not address this initial issue, then I don't see a concrete reason to even discuss this as a problem that needs to be solved. That's why I asked before if we have data to support the assertion that those issues are sufficiently common.

I think you have summarized perfectly the current classification when you said "... although very simplified is already broken down by who can inject the payload and who can be affected by it. In this case we found it to be the best methodology that helps us stay consistent across all of our programs and set clear expectations for the researchers.", so I don't agree that the classification is oversimplified or inaccurate as you later said. If the concern is actually to classify complex attack scenarios, you have knowledgeable triagers that can use their judgment to classify such scenarios appropriately. The program owner can also change the classification and priority according to the business model. It is also important to keep in mind that complex scenarios are, by their nature, uncommon. Therefore, it is probably not a good idea to try to create rules around such scenarios.

[plr0man]

The alternative in this case would be to downgrade our current Cross-Site Scripting (XSS) > Stored > Admin to Anyone from P3 to P4. That would shift the upgrade responsibility based on context onto the triage phase. Although I am afraid that this approach would result in overall lower ratings as opposed to the proposed solution especially in case of less experienced researchers.

[ghost]

That's an interesting idea, although I think it is a bit unfair to use P4 as a baseline for a perfectly good and exploitable XSS, particularly when the same category includes things such as weak login function (#180). Furthermore, complex scenario are probably not restricted to interactions of the type Admin to Anyone at least in theory. Having said that, I completely agree with a shift in responsibility in order to demonstrate impact.

I suppose another option is to add a category for XSS with priority "Varies" to explicitly manage complex scenarios, but that's probably unnecessary because it is already understood for almost all categories that context is extremely important. For example, XSS in feature to allow customization of forms via javascript. The company can't have that feature without the inherent risk of XSS and therefore, it is prioritized as P5.

[plr0man]

@rsmith31415 we had a chance to review your feedback yesterday and after considering all options with their pros and cons the team has decided to implement the changes as originally proposed (based on privileges). Thanks for diving into it and all of your thoughtful comments.

[ghost]

@plr0man So what is going to be the new classification and how are you going to make sure it doesn't become a source of discussion or misinterpretation between researchers and analysts? (which is what I'm most concerned about). At the very least it should be extremely well-defined.

[plr0man]

@rsmith31415 you can review the changes in #182. If the new classification turns out to become problematic at triage we can go back to the drawing board.

[ghost]

Yes, it looks like https://github.com/bugcrowd/vulnerability-rating-taxonomy/issues/166#issuecomment-401427179.

If the new classification turns out to become problematic at triage we can go back to the drawing board.

Fair enough. Can you define Privileged User to No Privilege Elevation (P4)? The initial idea was to assess situations in which the attacker already has all the privileges of the victim and nothing can be gained from the attack, but the proposed classification didn't address the original issue. For example, XSS from admin to users allowing the administrator to read private messages from users is considered Privileged User to Privilege Elevation (P3) or Privileged User to No Privilege Elevation (P4) ? I suppose it is P3, but then what would be a classic example of P4?