"Subdomain Takeover" prioritization

Right now subdomain takeover is classified with a base severity of P2, per VRT. I think it should be changed to varies: it would require researchers to prove impact (or at least potential impact), for what is a vulnerability type with wildly varying impacts.

Some potential impacts I’ve come up with quickly:

• Subdomain is still receiving data from other systems (this could be sensitive data, like CC data or session tokens, potential P1 - other kinds of data, evaluated on a case-by-case basis)
• Subdomain is in a Oauth redirect_uri whitelist, and can be used to steal Oauth tokens (likely a P2, as per current VRT for those issues)
• Subdomain is on the CORS whitelist for some other domain (impact varies, should be judged as CORS issues normally are)
• Main domain sources Javascript from the subdomain - this leads to Stored XSS on the main domain (likely P2)
• Main domain cookies are widely scoped, and the subdomain can access them (as this is essentially equivalent to a RXSS on main domain - you still need to trick user into visiting a subdomain which is likely not often used - likely P3)
• Subdomain can be used to facilitate CSP bypasses on core domains (if whitelisted there), thus allowing XSS on those (likely P3)
• Subdomain can be used for the researcher to put up cat pictures and cause brand image damage (likely P5, unless it happens to be an important subdomain with considerable organic traffic. Maybe P4.)

Probably plenty more, and I welcome additions or corrections, this is just a quick list off the top of my head which hopefully demonstrates how varied the impact for this VRT entry really is. Reports that are just “I can take over subdomain X” should get a reply asking for impact.

[jhaddix]

Hey All,

We looked into the data here. 72% of these submissions were kept as-is, while 28% were downgraded. Some are downgraded for impact and some get downgraded because they are not in or out of scope explicitly. With this in mind (and a consensus from the whole ASE team) we decided on the following:

P2 - Server Security Misconfiguration   >  Misconfigured DNS  >  Subdomain Takeover > High Impact (like Stored XSS, CORS Cookie sharing, high traffic subdomain)

and

P3 - Server Security Misconfiguration  >  Misconfigured DNS >  Subdomain Takeover > Medium Impact (like Reflected XSS, No CORS Cookie sharing, low traffic subdomain)

We really appreciate the feedback and hope to hear more in the future! Also be on the lookout for communication on leaderboard changes next week!

[melardev]

@hakluke Hi and thanks for the detailed response and discussing this issue internally. I know you won’t discuss it anymore because you just did and it is fine, but let me react with three points:

• I may agree in some points, but, it still is more than a reflected XSS, even more than a stored XSS, but not less, most stored XSS are P2, regardless of the subdomain, a subdomain takeover is somewhat more than that, or the least, deserves the same.
• About:

especially prominent subdomain

yes, but unfortunately this is not easy to prove for the reporter nor for the triager, and in my experience in multiple platforms, companies don’t help to clarify this either, they take the report as given by the triager, sometimes two very similar bugs are forwarded with different severity, because the triagers are different, and the company did not change the severity to make them the same, they just took it as such.

• About:

If you were able to take over 14.staging.dev-environment.jenkins.example.com and host content there, it really wouldn’t affect the company much.

Well, maybe yes, but if you host, for example, a racist content in these times on a company’s subdomain, and you spread the word across the media you may end up with a company’s building on flames in a matter of minutes even if the hostname is not that “nice” (it belongs to the company anyway) … and the spokesperson rushing to appear on the media to explain what happened, these two drastic situations would not happen for a P3 issue such as an XSS.

I understand your side of having to make the VRT flexible, though, but it just seems not right to me sometimes when I get a report treated the same as if it would for a r-XSS.