bugcrowd / vulnerability-rating-taxonomy

Bugcrowd’s baseline priority ratings for common security vulnerabilities
https://bugcrowd.com/vrt
Apache License 2.0
443 stars 84 forks source link

Downgrade off-domain "XSS" using data urls to P5 #141

Closed devinlundberg closed 6 years ago

devinlundberg commented 6 years ago

Recently, I've seen open redirects being also re-submitted as "off-domain" XSS via data urls. I believe it should be re-evaluated as a vulnerability since it does not exist on modern browsers. In fact any browser that allows any cross domain access is violating the html spec which states that data urls are a unique origin (see https://html.spec.whatwg.org/#origin)

The last major browser I know of that did not support different origins for data urls is firefox which was fixed to enforce same origin policy correctly in 57 (https://bugzilla.mozilla.org/show_bug.cgi?id=1324406). This has been deployed since November and is widely adopted.

Given that the user is on a modern browser, the risk of redirecting to a data url is the same as redirecting to a site an attacker controls so it should not be considered a separated vulnerability. Allowing users to create links to data urls is similar in risk to allowing them to create links to arbitrary sites (maybe less so since the content cannot be changed).

Because data urls are treated as a different origin or outright blocked, there are no risks for cross site scripting in current versions of chrome, safari, internet explorer, opera, edge, or firefox and thus I think the priority here needs to be updated.

truemongo commented 6 years ago

I agree with this (and you made your case quite well), but perhaps for the time being, the priority for data: XSS should be downgraded, rather than outright removing it as a vulnerability. The rationale would be similar to the one for keeping XSS on older browser versions as P4 - users can be slow to update.

That seems particularly relevant here since, as you mentioned, it has not been that long since Firefox finally addressed this issue.

One thing that is of concern to me is your use of "re-submitted". Do you mean it is being submitted as both open redirect and XSS, separately? Because that should not be happening, IMO, and it seems like gaming the system, especially if it is the same researcher doing both reports.

Just my 2c.

devinlundberg commented 6 years ago

I've seen the same researcher submitting both and I've seen different researchers submit them differently. For either case, we generally mark these as duplicates with some explanation as to why they are the same, but this does appear to be a flaw with VRT.

Looks like there is about 1.2% market share stuck on Firefox 52 (last release for XP and vista; pulled the number from https://www.stetic.com/market-share/browser/ ). What is the threshold where Bugcrowd generally would feel comfortable not supporting a legacy browser in the VRT?

plr0man commented 6 years ago

Thanks for filing @devinlundberg and for your continued interest in this project @truemongo. We will discuss this issue on Friday if time permits and keep you updated. Regarding the self duplicate concerns, since those would be one root cause, we would not be accepting them as unique issues

plr0man commented 6 years ago

Because all of the recent changes data URI attacks become less and less practical. As far as I understand you are proposing a downgrade of the data URI XSS variant to P5 in favor of being able to report an open redirect. On the other hand open redirects via data URI are not that simple in most browsers now, here's an example from Mozilla: Blocking Top-Level Navigations to data URLs for Firefox 59 (or https://bugzilla.mozilla.org/show_bug.cgi?id=786275)

We might consider downgrading data URI XSS to P5 but only if all potential data URI attacks would allow both XSS and open redirect. For instance, the object HTML tag allows data URI XSS, but does it allow open redirects etc.?