Submit bug report: https://liberapay.com@liberapay
Disclosure policy
We will investigate legitimate reports and make every effort to quickly resolve any vulnerability. Please make a good faith effort to avoid privacy violations, destruction of data, and interruption or degradation of our services.
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 “authorised” conduct under the Computer Fraud and Abuse Act. We will not bring a DMCA claim against you for circumventing the technological measures we have used to protect the applications in scope of this program.
If legal action is initiated by a third party against you and you have complied with this security policy, we will take steps to make it known that your actions were conducted in compliance with this policy.
It is also important to note, we will not take legal action against you simply for providing us with a proof of concept of the security vulnerability. Please follow the guidelines listed in the Proof of concepts section below to ensure that your proof of concept is detailed enough to demonstrate the issue and still follows the guideline listed above.
⛔ Don't…
Don't create accounts with fake email addresses, our sender reputation is negatively impacted when messages bounce back.
Don't flood our production website with requests. If you want to scan our production website for vulnerabilities you must do so at a slow pace — no more than 3 GET or HEAD requests per second and no more than 1 request per second for "unsafe" methods (POST, PUT, etc.) — otherwise you will hit rate limits and your scan results won't be accurate since most of your requests will be ignored (a 429 HTTP status code will be returned). If you want to try more intensive scans you can run the Liberapay webapp locally, installation instructions can be found in
https://github.com/liberapay/liberapay.com#installation. Make sure to always test the latest version:
https://github.com/liberapay/liberapay.com/releases.
Don't send any potentially damaging payload when attempting to find or confirm a remote code execution vulnerability.
Don't attempt physical testing such as office access (e.g. open doors, tailgating).
Don't attempt social engineering (e.g. phishing, vishing).
🎯 Target dummy accounts
To demonstrate the impact of your findings, please feel free to exploit them against
https://liberapay.com/hackerone-target if you can. This will give us an idea of what you are capable of doing against a victim's account on the Liberapay platform.
Since Liberapay is a platform to donate money, the vulnerabilities we're most interested in are those that could allow an attacker to disrupt or divert donations, as well as those that an attacker could exploit to obtain private user information.
Low-severity issues will not be rewarded because we operate on a small budget, but we usually close those reports as resolved to award some reputation.
🚫 Known issues
Before reporting a potential vulnerability please check that it's not already in our list of known low-risk issues:
https://github.com/liberapay/liberapay.com/labels/Defense🖼 False positives
We want to make sure you do not waste your time if you stumble across something that might appear like an issue at first, but turns out to be an accepted risk or not a security vulnerability. We created this section in the hopes that you will not panic if you come across these non-issues.
Our GitHub repository might appear to leak credentials (e.g. in the app-conf-defaults.sql file), but these are simply test credentials and exposing them is an accepted risk.
Issues related to username and page name collisions; i.e. being able to set a page name as your username. We are already aware of this and will eventually fix this properly.
Almost all CSRF-related reports are false-positives. Make sure you can exploit the issue across two accounts in two separate browser sessions, preferably in incognito mode. (We often get reports claiming that our anti-CSRF mechanism is broken, but it isn't. An anti-CSRF cookie doesn't need to be authenticated by the server, because a cross-site attacker cannot modify the cookies of the attacked domain.)
Our wikis are meant to be publicly-editable.
If you are not sure about whether something belongs to us or not, please feel free to either submit a report or email contact {at} edoverflow {dot} com with your questions. If you submit a report, we will let you self-close it afterwards so as not to affect your reputation.
⛔ Exclusions
Don't submit:
Reports of vulnerabilities in applications or systems not listed in the "Scope" section, unless you've found a high-severity issue that directly affect us. Issues in third-party services should be reported to the respective team.
Vulnerability reports with video only PoCs.
Reports that state that software is out of date or vulnerable without a proof of concept.
Highly speculative reports about theoretical damage. Be concrete.
Vulnerabilities as reported by automated tools without additional analysis as to how they’re an issue.
