Sensitive service/login panel/file disclosure context-based entry classification and prioritization

The VRT includes a number of intentionally-limited entries designated as varies due to both the technical and policy-based context necessary to prioritize. I believe we have an opportunity to clarify several similar issue categories to encourage thoughtful conversations about risk, design, and incentivization outcome. Related to yet distinct from HTTP risk/reports (see: #180) we have additional work to do here.

The categories include but are not limited to:

• FTP / Sensitive Service usage
• Potentially-sensitive resource exposure
  • Login panels
  • Diagnostic/status pages (Apache modules, phpinfo(), etc.)
  • Webserver root directory files

I propose we create appropriate high-level categories to classify these issues as varies for the following benefits:

• Consistent classification across all bug bounty programs utilizing the VRT
• Consistent outcome expectation setting, as pertains to priority, acceptance, and necessary risk discussion
• Positive impact to the Bugcrowd platform kudos economy related to and dependent upon VRT, e.g. kudos-only program balance, open scope programs, platform-wide incentivization mechanics (leaderboard)

Issue #136 raised this concept for FTP alone and I believe that due to the above, combined with hard data observations, we should revisit this topic for the benefit of VRT in clarity but also the platform itself.

[truemongo]

Strong +1 on this. I feel these issues (along with HTTP risk stuff) should all be varies, its not enough to just downgrade their baseline priority. Marking them varies would force a discussion about risk that seems really important in these cases, and does not currently happen. Further, the “risk” for these categories is often known apriori and accepted by the clients, in which case there should be no rewards (kudos or financial).

Most vulnerability types require some sort of proof of exploitability / impact, while right now these are basically providing a kudos “free for all”. This is even more noticeable on kudos-only programs, where the bar to acceptance is lower, and the customers have little incentive to argue about risk/exploitability/root cause/etc, given its easier to just accept reports as they come (no financial consequences).

My thought on theses matters, which I’ve expressed often before, in a variety of ways, but with the hope I was a bit more eloquent this time.

[ryancblack]

Closing this issue as no action needed after RFC.