The Vulnerability Rating Taxonomy (VRT) is a living project that is continually updated thanks to contributions from the broader security community to our open-sourced GitHub repository. Today, Bugcrowd is thrilled to announce the culmination of these most recent efforts, VRT 1.9.

CREDENTIAL EXPOSURES

Sensitive Data Exposure vulnerabilities are amongst the top five most common submissions on the Bugcrowd platform, though they vary widely in form, and severity. VRT 1.9 replaces the entire Sensitive Data Exposure -> Critically Sensitive Data subcategory with a new, more granular classification that ranges in severity baselines from P5-P1.

Previously, researchers had little choice but to report any password or API key disclosure as P1, which has created a considerable amount of noise. Now with the revamped subcategory there’s a wide variety of choices, for instance a Google Maps private API key disclosure could be classified as a P4: Sensitive Data Exposure -> Disclosure Of Secrets -> Pay Per Use Abuse, while Sensitive Data Exposure -> Disclosure of Secrets for publicly accessible assets is classified as a  P1. To provide a holistic approach, the VRT also includes suggested remediation steps for vulnerabilities of this type.

NEW ENTRIES FOR COMMONLY SUBMITTED REPORTS

VRT 1.9 also adds several new entries for commonly submitted reports that have grown in popularity over the last six months. This includes SSTI, Impersonation via Broken Link Hijacking or Password Policy Bypass.

FLASH-BASED CSRF

Flash is nearing its end of life and as we continue to downgrade Flash-based types of issues, the time has come for Flash-based CSRF dedicated entries, which will range from P5-P4.

To enumerate the above and to capture any outstanding, the updates to VRT 1.9 include:

Added

  • Sensitive Data Exposure -> Disclosure of Secrets -> For Publicly Accessible Asset
  • Sensitive Data Exposure -> Disclosure of Secrets -> For Internal Asset
  • Sensitive Data Exposure -> Disclosure of Secrets -> Pay-Per-Use Abuse
  • Sensitive Data Exposure -> Disclosure of Secrets -> Intentionally Public, Sample or Invalid
  • Sensitive Data Exposure -> Disclosure of Secrets -> Data/Traffic Spam
  • Sensitive Data Exposure -> Disclosure of Secrets -> Non-Corporate User
  • Sensitive Data Exposure -> Via localStorage/sessionStorage -> Sensitive Token
  • Sensitive Data Exposure -> Via localStorage/sessionStorage -> Non-Sensitive Token
  • Server-Side Injection -> Server-Side Template Injection (SSTI) -> Basic
  • Server-Side Injection -> Server-Side Template Injection (SSTI) -> Custom
  • Server-Side Injection -> Content Spoofing -> Impersonation via Broken Link Hijacking
  • Mobile Security Misconfiguration -> Auto Backup Allowed by Default
  • Server Security Misconfiguration -> No Rate Limiting on Form -> Change Password
  • Cross-Site Request Forgery (CSRF) -> Flash-Based -> High Impact
  • Cross-Site Request Forgery (CSRF) -> Flash-Based -> Low Impact
  • Insufficient Security Configurability -> Password Policy Bypass

Removed

  • Sensitive Data Exposure -> Critically Sensitive Data -> Password Disclosure
  • Sensitive Data Exposure -> Critically Sensitive Data -> Private API Keys
  • Sensitive Data Exposure -> Critically Sensitive Data

We know that every company has different priorities and needs. Because of this, we work with our customers to help them define any potential deviations from our VRT as well as any other program brief customizations.

The VRT 1.9 update will be implemented into the Crowdcontrol platform on July 13, 2020.

WHAT IS THE VULNERABILITY RATING TAXONOMY (VRT)?

Created with consideration of common vulnerability standards such as the OWASP, the VRT is a living document that is constantly evolving to best provide a baseline priority rating system for vulnerabilities reported within our platform, Crowdcontrol. Our VRT Council consists of several members of the Bugcrowd team who meet each week to discuss vulnerability edge cases, improving vulnerability classification, and all external feedback from the official VRT GitHub repository. Open sourcing our VRT enables us to keep our ear to the ground, ensuring that the taxonomy aligns with the market.

At  any time, you can visit the changelog to keep up to date with a fully detailed list of changes made to the VRT. We also encourage you to follow our repository and contribute to it in any way you can.  

Managing the VRT as a living document has proven to be an effective strategy for us, as the security landscape is constantly evolving. We’d like to thank everyone involved in this project and are off to start work on even more improvements!

 

Tags: