Banner object (1)

Hack and Take the Cash !

684 bounties in database
02/06/2018

Reward

50 $ 

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.

???? 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.

{F320809}

This dummy account is very privacy oriented and has all the privacy settings enabled.

{F320808}

We have also set up a target team account on https://liberapay.com/hackerone- target-team __. Once again, this is a very privacy-oriented team.

{F320813}
{F320810}

Finally, there is a target community too: https://liberapay.com/for/hackerone-target-community __.

{F320812}

???? Service-level agreement (Performance expectations)

We will make a best effort to meet the following expectations for hackers participating in this program:

Time to first response: 2 business days or less.
Time to triage: 3 business days or less.

???? In-scope

All projects listed in the "In Scope" section at the very bottom of this page are in scope of this program.


We highly recommend running Liberapay locally so that you can scan the application and not affect our production services ' up-time. Installation instructions can be found here: https://github.com/liberapay/liberapay.com#installation __. Make sure you have the latest version installed while testing: https://github.com/liberapay/liberapay.com/releases __. If you plan on scanning our production systems, please limit your scans to 5 requests per second to avoid degrading performance for our users.


???? Rewards

Severity | Bounty Amount | Threat model
---|---|---
Medium (4.0-6.9) | $50-$100 | Medium-severity issues tend to require user- interaction and the scope of the attack is usually narrowed down to a single user.
High (7.0-8.9) | $300 | Issues that affect a large portion of the platform and would require immediate action to prevent from spreading.
Critical (9.0-10.0) | $500 | Attacks that can completely compromise the integrity, the authenticity, and potentially the availability of our services are our biggest priority.

Since Liberapay is a platform to donate money to teams, organizations and individuals, any issues that affect an account's wallet is going to be a high- priority issue that we will want to fix quickly.

Low-severity issues will not be rewarded, 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.
  • Most CSRF-related reports will most likely be false-positives. Make sure you can exploit the issue across two accounts in two separate browser sessions, preferably in incognito mode.
  • 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

The following test types are excluded from the scope:

  • Findings from physical testing such as office access (e.g. open doors, tailgating).
  • Findings derived primarily from social engineering (e.g. phishing, vishing).
  • Findings from applications or systems not listed in the "Scope" section. I do accept high-severity issues on out of scope assets if they directly affect me.
  • 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.
  • Issues in third-party services should be reported to the respective team.

The following issue types are excluded from scope:

Description | Reason
---|---
Network-level Denial of Service (DoS/DDoS) vulnerabilities. | We do not want you to disrupt any of our services.
Low severity issues that can be detected with tools such as Hardenize __and Security Headers __. | We run regular scans with these services and try to improve our score gradually.
Content injection issues. | The severity of this issue is so low that it does not warrant a report.
Cross-site Request Forgery (CSRF) with minimal security implications (Logout CSRF, etc.). | In order for CSRF to be a valid issue it must affect some important action such as deleting one's account.
Missing cookie flags on non-security-sensitive cookies. | These type of issues do not present a major risk and are usually picked up by scanners.
UI and UX bugs (including spelling mistakes). | No comment.
401 injection. | This is usually an accepted risk and we are already aware of this issue: https://github.com/liberapay/liberapay.com/issues/504 __.
Stack traces that disclose information. | All of our projects are open-source therefore this information is usually public knowledge. That said, if you discover a stack trace that discloses information which is not located in our GitHub repositories, please do submit a report.
Host header issues without an accompanying proof-of-concept demonstrating vulnerability. | We require a clear proof of concept.
Open ports without an accompanying proof-of-concept demonstrating vulnerability. | Same as above.
Banner grabbing issues (figuring out what web server we use, etc.). | We will happily share what web servers we are running.
Missing X-Frame-Options header (Clickjacking) | The lack of X-Frame- Options does not always indicate that a security vulnerability is present. This is an optional header that is only necessary on endpoints where there UI is rendered to invoke state changing actions. We recommend reading this informative post by David Ross: https://plus.google.com/u/0/+DavidRossX/posts/jVrtTRd5yKP __
Cross-site tracing | In order for Cross-Site Tracing (XST) to really be a significant issue you would need to find an endpoint vulnerable to Cross-site Scripting (XSS).
CSP uses unsafe-inline | The fact that a CSP includes unsafe-inline is not an issue in itself. In order for you to demonstrate the actual impact of this value, we highly recommend you look for an XSS vulnerability. Try to trigger alert(document.domain).
Disclosure of robots.txt file | We are aware that in some cases robots.txt files have been known to disclose sensitive information. In our case we have determined that our robots.txt files do not contain any information that poses a potential security risk.
Email spoofing (SPF misconfigurations) | We have accepted the risk that this issue poses and do not believe that it warrants an immediate fix.
Open redirect using Host header | Open redirects in the Host header are not exploitable.

As a rule of thumb, pretty much everything listed below is a non-issue:

{F304365}

???? Proof of concepts

Issue type | When to report the issue
---|---
XSS | For XSS, a simple alert(document.domain) should suffice.
RCE | Please only execute harmless code. Simply printing something or evaluating an expression should be enough to demonstrate the issue.
SQLi | Report it as soon as you have a SQL error that indicates SQL injection or you are able to disclose the SQL server's version number.
Unvalidated redirect | Set the redirect endpoint to http://example.com __if possible.
CSRF | Either attach a file to demonstrate the issue or paste the code in a code block in your report.
SSRF | Do not go playing around on any internal networks. Report as soon as you believe that you have a potential SSRF issue and we will look into it for you.
LFI | The same applies here — please do not go against the guideline listed in the Disclosure policy section. We investigate LFI reports in a dev environment to make sure it is valid.

???? Advice

We encourage hackers to read Web Hacking 101 __and Breaking into Information Security: Learning the Ropes 101 __to get a good idea of the type of issues that we are looking for.

???? Terminology

The term "severity" is frequently used interchangeably with "impact" or "priority". This section defines our terminology in order to prevent any potential confusion. We use the Oxford Dictionaries ' definition of "severity" and Information Technology Infrastructure Library 's definitions of the two latter terms.

Severity

The fact or condition of being severe.

Impact

A measure of the effect of an incident, problem or change on business processes. Impact is often based on how service levels will be affected. Impact and urgency are used to assign priority.

Priority

A category used to identify the relative importance of an incident, problem or change. Priority is based on impact and urgency, and is used to identify required times for actions to be taken.

Whenever we triage a report, a CVSS v3.0 Base Score metric is set which evaluates the technical severity of the reported issue and allows us to prioritise the fix. Once a patch has been submitted and verified, we will then evaluate the total CVSS score by including the Environmental Score.

Thank you for helping us keep Liberapay safe!

Thanks
Gift
Hall of Fame
Reward


List your Bug Bounty for free immediately!

Contact us if you want more information.

FireBounty (c) 2015-2018