✅ Rules

Rules for you

• Test and report against https://sandbox.opentech.fund and code found in our repositories at https://github.com/OpenTechFund/. Needless testing and reports on production domains may be marked not applicable.
• Don't attempt to gain access to another user's account or data.
• Don't perform any attack that could harm the reliability/integrity of our services or data. DDoS/spam attacks are not allowed.
• Don't publicly disclose a bug before it has been fixed.
• Only test for vulnerabilities on sites you know to be operated by OTF and listed under Open bounties. Some sites hosted on sub-domains of OTF are operated by third parties, and should not be tested.
• Do not impact other users with your testing, this includes testing for vulnerabilities in repositories you do not own.
• Never attempt non-technical attacks such as social engineering, phishing, or physical attacks against our employees, users, or infrastructure.
• When in doubt, contact us at [email protected].

Rules for us

• We will respond as quickly as possible to your submission.
• We will keep you updated as we work to fix the bug you submitted.
• We will not take legal action against you if you play by the rules.

What does not qualify

• We are not interested in social engineering reports
• We are not interested in version disclosure reports
• Attacks requiring physical access to a user's device.
• We are not interested in HTTP sniffing or HTTP tampering exploits, our sandbox is HTTPS and you can assume all live Discourse instances will be HTTPS.
• Bugs that don't affect the latest version of modern browsers (Chrome, Firefox, Edge, Safari). Bugs related to browser extensions are also out of scope.
• Bugs requiring exceedingly unlikely user interaction.
• Submissions which don't include steps to reproduce the bug, or only include those steps in video form.
• Bugs, such as timing attacks, that prove the existence of a private repository or user.
• Insecure cookie settings for non-sensitive cookies.
• Disclosure of public information and information that does not present a significant risk.
• Bugs that have already been submitted by another user, that we are already aware of, or that have been classified as ineligible.
• Bugs in applications not listed as In Scope are generally not eligible.
• Bugs in content/services that are not owned/operated by OTF.
• Vulnerabilities that OTF determines to be an acceptable risk will not be eligible for a paid bounty or listing on the site.
• For guidance, we have listed the Vulnerability classifications we use to organize submissions made to the Bounty program.
• When in doubt, contact us at [email protected].

💵 Severity Guidelines and Payouts

All bounty submissions are rated by OTF using a purposefully simple scale. Each vulnerability is unique but the following is a rough guideline we use internally for rating and rewarding submissions:

We will triage into:

• Not applicable (Durp)-- Reports about things that we have specifically noted as out of scope.

• Informative (Thanks) -- We're aware of this, or we don't really see it as a security issue.

• Low ($25-100) -- Low severity issues allow an attacker to access extremely limited amounts of data. They may violate an expectation for how something is intended to work, but it allows nearly no escalation of privilege or ability to trigger unintended behavior by an attacker. For example:

  • creating a comment that bypasses our filters by providing a malformed URL.
  • triggering verbose or debug error pages without proof of exploitability or obtaining sensitive information.
  • triggering application exceptions that could affect many OTF users.
  • a public security issue (like a CVE) for a dependency or platform we rely upon - but it also works on OF. It's not new: we really should have known about it.
  • a bug appropriately categorized as a security issue but doesn't present much risk and isn't a priority to fix.
  • a minor security problem. Someone should probably fix it. It's likely not getting fixed in the next release.

• Medium ($100-200)-- Medium severity issues allow an attacker to read or modify limited amounts of data that they are not authorized to access. They generally grant access to less sensitive information than high severity issues. For example:

  • disclosing the title of issues in private repositories which should be be inaccessible.
  • injecting attacker-controlled content into opentech.fund (XSS) but not bypassing CSP or executing sensitive actions with another user's session.
  • bypassing CSRF / exploit that causes a user to perform an operation they didn't explicitly consent to

• High ($200-500) -- High severity issues allow an attacker to read or modify highly sensitive data that they are not authorized to access. They are generally more narrow in scope than critical issues, though they may still grant an attacker extensive access. For example:

  • injecting attacker-controlled content into opentech.fund (XSS) which bypasses CSP.
  • bypassing authorization logic to grant a user more access than intended.
  • discovering sensitive user or OTF data in a publicly exposed resource, such as an S3 bucket.
  • gaining access to a non-critical resource that only OTF employees should be able to reach.

• Critical ($500-1000) -- Critical severity issues present a direct and immediate risk to a broad array of our users or to OTF itself. They often could affect relatively low-level/critical components in one of our application stacks or infrastructure. For example:

  • Exploit resulting in privilege escalation to admin, or downloading the site database
  • arbitrary code/command execution on an OTF server in our production network.
  • arbitrary SQL queries on the OTF production database.
  • bypassing the OTF login process, either password or 2FA.
  • access to sensitive production user data or access to internal production systems.

👁‍🗨 Disclosure Policy

• Security issues always take precedence over bug fixes and feature work. We can and do mark releases as "urgent" if they contain serious security fixes.
• 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. We may publicly disclose the issue before resolving it, if appropriate.
• 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.
• If you would like to encrypt your report, please use the PGP key (insert here)
• We are generally happy to publicly disclose reports two weeks after shipping the release which contains the fix.
• We will publicly acknowledge any report (unless you request otherwise) that results in a security commit to https://github.com/opentechfund/opentech.fund

Thank you for helping keep OTF and our users safe!