Add UXSS for browser plugins and browser

[Abr1k0sHelm]

As per the VRT UXSS is a P4. But there is a feeling that here it is in the context of the security of the web site, and not browser plug-ins / browsers. I mean that when you made the VRT, you probably had in view of vulnerabilities like CVE 2015-0072 (you must put the x-frame-options header at your site to protect). Please add UXSS (SOP bypass) for browsers and browser plug-ins (looks like this should be P2 or P1). If i can inject js at every site - it seems to be not P4.

Examples: CVE-2016-5208 CVE-2016-5207 CVE-2016-5205 https://www.blackhat.com/docs/asia-16/materials/asia-16-Baloch-Bypassing-Browser-Security-Policies-For-Fun-And-Profit.pdf etc..

[plr0man]

In case we were running a program for a specific browser or plugin, P4 would clearly not apply as we would be looking at a different impact and different rating methodology. The priority could go as high as P1, but what you describe would be an exceptional scenario and adding an entry for every possible exception is just not something we can do. Fortunately the VRT allows us to adjust the default priority on a case by case basis. You can learn more about our rating methodology from the VRT PDF that can be found on this page.

Hope this clarifies things. Let me know if you have any other questions.

[Abr1k0sHelm]

I report a vulnerability in the browser plug-in that allows you to execute js in the context of any site and in the context of the plugin itself (UXSS - SOP bypass). But due to the fact that on this page https://bugcrowd.com/vulnerability-rating-taxonomy UXSS is specified as P4 - the vulnerabilities set the priority of P4

[plr0man]

The paragraphs below (which can be found in the PDF mentioned earlier) provide good insight into how we use the VRT guidelines and how to go about upgrading the priority:

Priority is a Baseline
The recommended priority, from Priority 1 (P1) to Priority 5 (P5), is a baseline. That
having been said, while this baseline priority might apply without context, it’s possible
that application complexity, bounty brief restrictions, or unusual impact could result in
a different rating. As a customer, it’s important to weigh the VRT alongside your internal
application security ratings.

For bug hunters, if you think a bug’s impact warrants reporting despite the VRT’s
guidelines, or that the customer has misunderstood the threat scenario, we encourage
you to submit the issue regardless and use the Bugcrowd Crowdcontrol commenting
system to clearly communicate your reasoning.