If an application's code contains even minor and subtle inaccuracies, it can open up the entire database to SQL injection. In this example (see section 'Delete All Method'), the entire Users table gets deleted with a trivial SQL injection ("1) OR 1=1--").
This had me wondering, have any white hats / bounty hunters (perhaps amateurs) looked for vulnerabilities and accidentally caused massive, real damage to the site/app/business? How do bounty programs deal with such a risk?
Sure. As you pointed out, some SQL injection vectors may inadvertently cause data deletion. Similarly, a persistent XSS attack may trigger in the browser of a real user. Or unusual characters in a username may crash a web application backend due to an unhandled encoding error.
More generally, a large part of black box pentesting involves experimenting with unexpected/invalid input to the target application. Some level of fuzzing is usually unavoidable - and this always carries the risk of causing behavior that breaks the application or corrupts data. So, while blindly trying out DELETE queries may be reckless and avoidable, vendors have to face that even benign bug hunting occasionally impacts service integrity or availability.
This report is an example of where the researcher caused a DOS by submitting invalid data. I'm entirely sure there are more severe examples, many of which simply weren't made public. Anecdotally, I remember several occasions where bug hunters were banned from programs because the tools they used were too disruptive.
A testing environment. While some bug bounties assume you're testing against production, many provide a separate sandbox and only allow you to test there. E.g., the program of Bitmex includes the rule:
Only test on testnet.bitmex.com.
A "responsible research" policy which asks that hunters make an effort to avoid damage. Rules would include not accessing real user data, limiting automated testing tools, etc. For example, Facebook's program demands:
You make a good faith effort to avoid privacy violations and disruptions to others, including (but not limited to) unauthorized access to or destruction of data, and interruption or degradation of our services. You must not intentionally violate any applicable laws or regulations, including (but not limited to) laws and regulations prohibiting the unauthorized access to data.
An emergency contact point. Some providers instruct hunters how to notify them immediately if their actions have caused service disruption. From the program of Exodus:
If you do accidentally cause some noticeable interruption of service, please immediately email us so we can handle it accordingly [email protected] and please include the subject title "HackerOne Outage: " for the alert to trigger.
Nowadays, many program policies come with a safe harbor clause. This is intended to protect hunters from liability if they act in good faith, even if their actions have caused damage. Since IANAL, I can't comment on the effectiveness of such a policy, but it's an established practice. Here is an example of a safe harbor clause in the program of Dropbox:
We will not pursue civil action or initiate a complaint to law enforcement for accidental, good faith violations of this policy. We consider activities conducted consistent with this policy to constitute “authorized” conduct under the Computer Fraud and Abuse Act. To the extent your activities are inconsistent with certain restrictions in our Acceptable Use Policy, we waive those restrictions for the limited purpose of permitting security research under this policy. We will not bring a DMCA claim against you for circumventing the technological measures we have used to protect the applications in scope.
You'll find a similar passage in the rules of most large programs.
Your question appears to assume that the attacker in question is working against a production system. To Fire Quacker's point, if you break someone's production system you're just as liable as any other attacker regardless of your white hat intentions (assuming it is not allowed as a part of a bug bounty program). And this is why bug bounty programs should set up special instances for testing that are not in production.
Robust systems should not only resist attacks but demonstrate viable recovery mechanisms. The cost of bugs may be less than bad design. Do you have logs? Can you use them to recover quickly? Production systems may have vulnerabilities like DOS that test systems lack!
