hakluke/bug-bounty-standards

A list of edge cases that occur in bug bounty programs, conversations on how they should be handled. The goal is to standardise the way that specific situations are handled in bug bounties.

What is This Repository?

This repository is a list of situations that occur in bug bounty programs and how they should be handled. Many of these are currently handled on a case-by-case basis, which leads to a lot of uncertainty and frustration from hackers, program owners and platforms. The goal of this repository is to standardise the way that these edge-cases are handled across all bounty platforms and programs. Hopefully standardization will allow expectations to be fulfilled more frequently from all parties.

This is a Draft

This document is a draft, and not yet implemented by any bug bounty platforms. At this stage, I am requesting comments from all interested parties.

How to Contribute

Please contribute by opening GitHub issues. All reasonable issues submitted will remain open for a minimum of 30 days for comments.

Your issue should state an opinion, e.g.

• I feel that a scenario should be added for when a hacker reaches out directly to the program directly instead of reporting through the provided platform.
• I feel that a scenario should be added for one party is abusive to another.
• I feel that the resolution for scenario 4 should be changed to "hacker is able to publicly disclose vulnerability after 120 days of non-response".

Comments on the issue are welcome by anyone, but must be constructive and unemotional. Abusive behaviour will not be tolerated.

The Table

ID	Situation	Resolution
1	Hacker submits vulnerability with proof of exploitation. The vulnerability is fixed before the submission is triaged.	Platform must provide proof that the submission was not accessed by the program prior to resolution. If the submission was accessed by the program, the program should pay the relevant bounty, otherwise submission is marked as duplicate.
2	Hacker submits vulnerability, program responds saying that they already knew about it internally.	Program must provide proof that this was a previously known issue, for example, a screenshot of a Jira ticket including the date created. If the program is unable to provide proof, they should pay the bounty, otherwise the submission should be marked as a duplicate.
3	Hacker submits vulnerability, it is marked as a duplicate of another submission that did not fully explore the impact of the bug. For example, a hacker submits a full XSS which allows an account takeover, and dupes against another submission that only reported HTML injection.	The first reporter receives a bounty based on the impact of their submission, the second reporter receives a bounty based on the impact of their submission minus the bounty received by the first reporter.
4	Hacker submits vulnerability, the program never responds.	Platform pays the bounty.
5	Hacker submits vulnerability, hacker is incorrectly duped against a newer report.	Platform changes the status of both reports to be accurate. If payment has already been made incorrectly, the organization who triaged incorrectly pays the bounty. For managed bounty programs this would generally be the platform, but for unmanaged programs this would be the program.
6	Hacker disagrees on the assigned severity rating.	Hacker submits reasoning to ticket. If there is no response for 14 days, hacker submits reasoning to the platform's support channel. Severity upgrades are decided on a per-submission basis.
7	Hacker publicly discloses a bug that has been previously submitted to the platform, without explicit permission from the program owner.	A researcher should be able to publicly disclose the vulnerability under the following circumstances: a) The bug has not been accepted as valid, i.e. it has been marked as N/A or Informative. b) The bug has been in a resolved state for 30+ days. c) The researcher has explicit permission to publicly disclose from the program. In other cases, the hacker receives 30 day ban from platform, hacker is emailed with full reasoning behind ban. Repeat offence results in permanent ban.
8	Hacker submits a bug that is within scope of the program, but is actually a bug in a third-party service.	Every program should specify whether they accept bugs on 3rd party systems within their brief. If there is no specification, then it is assumed that ALL systems listed in the scope will be valid for payment, including 3rd party systems.
9	Hacker submits a zero-day vulnerability with no public exploits or disclosure existing, affecting in-scope systems.	If any changes were made as a result of the report, i.e. configuration changes, taking systems offline, or applying WAF rules, the report should be accepted and rewarded. A distinction has to be made between zero-day exploits that are public, vs. zero-day exploits that your team would not have known about if it weren't for the bug bounty report.
10	Hacker submits a bug to a program that has an open scope brief. The bug is on an acquisition. The program owner does not control the IT infrastructure or staff of the acquisition.	The program owner should make a good faith effort, verified by the platform, to inform the acquisition. Should the acquisition benefit from the submission, the program owner should pay the bounty. The brief should be updated to reflect if acquisition(s) are in scope.

bug-bounty-standards's Issues

Variant of ID 8: Acquisition

Hacker submits a bug to a program that has an open scope brief. The bug is on an acquisition. The program owner does not control the IT infrastructure or staff of the acquisition.

Resolution: The program owner should make a good faith effort, verified by the platform, to inform the acquisition. Should the acquisition benefit from the submission, the program owner should pay the bounty. The brief should be updated to reflect if acquisition(s) are in scope.

Scope attribution

Hacker exploits a vulnerability on site1.com through an endpoint on site2.com. The triager attributes the exploit to site2.com which has a lower reward amount.

Resolution:
A triager and program should make a good faith effort to attribute a vulnerability to the highest paying impacted resource.

Open/triaged report left without update for >12 months

Issue: Report is open/triaged for more than 12 months. There is no update from the program for several reasons:

• an asset which report was referring to does not exists anymore (was decommissioned by the program, rebuild with different tech stack and vulnerability is no longer present/not reproducible etc.)
• program is no longer active or was closed before the report was resolved

Despite several requests for update from Hacker, there is no clear response from either a program or platform's triage team.

Prerequisites

• vulnerability was valid at the moment it was reported, and report itself follows all requirements of valid report
• there was no bounty awarded
• report is open/triaged for more than 12 months and there are at least 180 days since the latest activity in the report (update form the platform/program etc.)

Proposed resolution: Platform should respond in <90 days with proposed ways of resolution. Report should be closed either as Informative if there is no clear way to determine the real impact/validity of reported vulnerability (no PoC, screenshots etc.) or as Resolved, if there is a clear evidence that the vulnerability in fact was found and reported in the expected way (report contains screenshots, PoC, video, detailed reproduction steps etc.) and the severity is at least Low

I believe the details about the final state of the report depends on the platform, but in general report should be handled in favor of the Hacker (so it should counts as a valid report, allows to gain reputation or other points awarded by the platform etc.).

Other things to consider:

• if program was paying bounties for valid, resolved reports - what is expected from the platform to be done in such case
• should disclosure be allowed - if yes, who makes the final decision (Platform or Hacker, as platform is no longer a part here)

Exclusion

• report is open for more than 12 months, but program responds in a timely manner that is working on resolution and gives updates in response to Hacker's comments/requests for update

Rationale
I can confirm scenarios described in this issue exists. I have several reports stuck in such situation, some of them are open and triaged for around 4 years now.
Example: I was asked to verify fixes, applied to asset which is no longer even available online. When I commented on this, there was (and still there is not) any response from the platform's triage team member(s) for 9 months now. Report was triaged 3 years ago in a program where, according to statistics, 96% of reports "Meet response standards" defined by platform and average time to resolution is 6 months.

Retesting, Payments & when to open new report

Situation: Retests are currently not handled uniformly. Some programs offer a reward for retests, some don't. Some offer a reward for a bypass, some don't.

Resolution:
Programs should have the option to pay a flat amount for a retest. This should be optional and left to the program. No demand for a retest should take place without payment. If a bypass for the fix can be found (whether a retest was requested or not), a new report should be opened and rewarded.

Reasoning & Discussion:
Not sure how to handle it when the issue can be reproduced as-is (ie a retest was requested and/or the report was marked as resolved, but the issue still exists in its original form). For a bypass, there's a new vulnerability which warrants a new report. But when the program is mistaken about having released a fix, it's not clear what to do. If a retest was requested, I think the retest payment is enough. Otherwise, I'm not sure if a new report is warranted.

Bounty range

Hacker submits a vulnerability with a CVSS score that sits within a programs specified reward range. The program rewards the report at the bottom of the specified range.

Resolution:
If a bounty range is published by a program, it should be made clear what reward a CVSS score would receive.

For example:
High Severity: Range $1000 - $3000
Vulnerability Score: 8.0
Reward: $2000

For any programs using CVSS, an approximate reward value for a submission should be automatically calculated and made visible to both reporter and program.

Vulnerability reversion

A hacker submits a report for a vulnerability that was previously reported and fixed and has become vulnerable again due to a reversion. The program closes as dupe due to previous report.

Resolution:
The program should pay the full reward amount.

Scenario

Hacker submits a bug but closed as duplicate. But after the old report closed as resolved, duplicated report still reproducible.

Resolution: Disclosed report status should changed to triage and, the program should pay the relevant bounty.

Disclosing a non-bug

Hacker publicly discloses details of a report that was previously submitted to a team. However:

• the team/platform has rejected the report as invalid
  OR
• the bug has already been confirmed to be fixed

Resolution: A platform ban seems excessive in these situations. A warning or a temporary program ban should me more than enough, given the very low risk of the disclosure being dangerous.

Standardizing a trivial punishment or no punishment for these situations would incentivize more accurate triage, and would probably remove a lot of friction from the process of publishing research.

Duping XSS on input rather than output

Situation:
From time to time, triage will close XSS reports as dupes based on input rather than output (so when eg a name input is echoed in entirely different pages/functionalities, they will close reports as dupes of each other). When appealing, it's sometimes resolved by the platform, sometimes passed onto the program to decide, and sometimes reports are left closed.

Resolution:
The platform should correctly triage reports (ideally directly, otherwise on appeal) & dupe XSS on output.

Reasoning:
XSS is an output vulnerability, and that's where the issue needs to be resolved. That's also how it's mostly - but not always - handled. Adding a generic input filter or WAF over the input will not properly fix the issue. Among other, already placed payloads will continue to trigger, allowing continued exploitation.

VDPs outside of Platforms

Hi,

Since it covers only the platform related programs, can we expand it to non platforms VDPs too? Or I can create a separate repository for it.