Please make sure you do all of your testing on sandbox.reverb.com.
No technology is perfect, and Reverb.com believes that working with skilled security researchers across the globe is crucial in identifying weaknesses in any technology. If you believe you've found a security issue in our product or service, we encourage you to notify us. We welcome working with you to resolve the issue promptly.
Please do not interfere with our legitimate users while testing
Please use sandbox.reverb.com to conduct your testing. Do not use reverb.com for your testing or your program membership will be cancelled. Create your own data, do not interfere with existing data.
To test credit card flows like checkout, use these fake card numbers
Please do not use automated scans or DOS attacks
Any scanning or high-rate abuse of our site will lead to disqualification and suspension from the program. Please respect the user experience on our platform.
* Let us know as soon as possible upon discovery of a potential security issue, and we'll make every effort to quickly resolve the issue.
* Provide us a reasonable amount of time to resolve the issue before any disclosure to the public or a third-party.
* Make a good faith effort to avoid privacy violations, destruction of data, and interruption or degradation of our service. Only interact with accounts you own or with explicit permission of the account holder. Please don't spam or send excessive communications to existing user accounts, even in the sandbox environments.
To show our appreciation of responsible security researchers, Reverb.com offers a monetary bounty for reports of qualifying security vulnerabilities. Reward amounts will vary based upon the severity of the reported vulnerability, and eligibility is at our sole discretion. These are the guidelines that we use when determining bounty rewards. All rewards are subject to Reverbs discretion. Not all bugs submitted will be rewarded. Duplicate issues will be merged.
Reverb is attempting a public bounty program late March 2018. During the transition, we expect an influx of reports. Until April 15 2018, responses to your bounties may be delayed as we triage reports by severity. If this is not acceptable to you, please do not participate in the public launch until after this date.
We reserve the right to transition back to a private program or pause new submissions at any time.
Bounty begging will get you kicked out
Our bounties are final and are not up for negotiation. Attempting to negotiate for bounties will result in termination from our program.
Exclusions - What qualifies for a bounty?
Please see google's bughunter university page: https://sites.google.com/site/bughunteruniversity/nonvuln - we follow the same rules.
Areas of highest interest
We are most interested in, and will pay higher bounties for the following items:
* Demonstrated XSS. In particular, stored and reflected XSS that leads to a victim loading an XSS planted by an attacker.
* Anything that allows bypass or gamification of the login system (aside from brute forcing or DoS).
* Things that exposes PRIVATE user data to other users in ways that are not intended. This means things like addresses, financial details etc - things like unpublished draft listings are not a security concern (see below).
Areas of lowest interest
* Best practice recommendations (DNSSEC, HSTS, SSL misconfiguration). You must demonstrate a security violation that results in modifying data or hacking someone's account.
* CORS - we get a lot of reports for CORS related stuff. We need a demonstrated vulnerability related to CORS if you want to report it. Querying our APIs via CORS is not a vulnerability, unless you can show exposure of sensitive information that would normally not be available.
* CSRF - The authenticity token for CSRF POSTS gets stored in the session cookie. If you are going to demonstrate a CSRF exploit, makes sure you test with the token removed from the cookie's contents as well.
* HTML input - some of our forms allow the submission and rendering of HTML. If you want to submit a vulnerability that is more than just a best practice, please show an actual exploit (such as credential theft or XSS).
* CVEs for versions of software you may identify we are running unless you can show an actual vulnerability
* IDOR - things like "I can craft a URL that lets me see unpublished draft listings" that you perform in Burp but not in the app itself. While it's certainly an issue, we view these more as bugs, not a huge security concern for us.
Out of scope:
* Cookie replay or session expiration based reports - sessions to do not expire on logout by design. They do expire on password reset.
* Rate limiting missing or not working - we are aware of our rate limiting policies
* Any and all reports regarding password policies, password complexity requirements, session timeout password change flows, password reset flows, email confirmations stemming from password changes, etc. We've evaluated our password requirements and we are satisfied with current policies.
* Best practices, such as "disabling autocomplete on forms"
* Image uploads - we use a 3rd party service for hosting images and other certain attachable items. We know you can upload things aside from images, this is by design. Unless you can find an actual exploit or hack of the reverb.com site, we're not concerned on this front.
While researching, we'd like to ask you to refrain from:
* Denial of service
* Social engineering (including phishing) of Reverb.com employees or contractors
* Any physical attempts against Reverb.com property or data centers
* POCs that require social engineering (for example, content injection) unless the content injection is truly sneaky.
Thank you for helping keep Reverb.com and our users safe!
Hall of Fame