WePay Bug Bounty Program Rules

WePay asks that tests are performed against stage-go.wepay.com, stage.wepay.com and stage.wepayapi.com. Our public staging server runs the same code as production. Create as many test accounts there as you feel necessary; actual customer data is strongly discouraged for exploits — a reproduce case will suffice. One report to cover both domains is sufficient; please perform testing against stage.wepay.com to prevent service interruption to our customers.

Vulnerabilities that may be specific to server configs (SSL settings,SSH settings, etc) may also be tested on go.wepay.com, www.wepay.com ,home.wepay.com and wepayapi.com, as the environments may be configured differently than their corresponding staging environments viz.; stage- go.wepay.com, stage.wepay.com, stage-home.wepay.com, and stage.wepayapi.com respectively.

Attributes of a good report:

1. Only one issue per report.
2. Summarize the Security issue in a single sentence
3. Describe detailed steps for reproducing the bug. If possible, please include video or screenshots, links you clicked on, pages visited, etc.
4. Elaborate Security implications of the issue. How will the problem affect WePay, our users or our partners? What's the worst thing that could happen if an attacker takes advantage of this security flaw.

> Functioning exploits are worth more money than reports that are copy- > pasted from other security-related websites. A screenshot is much less > useful than a video, and a functioning exploit will always have real code. > Showing that there's a potential issue is less valuable than exploiting > a real issue.

With Regard to Duplicates

If we have already received a report of a similar issue, which we believe would be resolved by the same fix that would resolve your issue, then we will mark your issue as a duplicate because the root-cause is the same.

With Regard to Reputation

If you make an effort to file a legitimate issue, and it is not necessarily a valid issue, we will generally close it as Informational (+0) — UNLESS it is clear that you made no effort to read these Guidelines, in which case we may choose to close as Not Applicable (-5) if the case is particularly egregious.

Following categories of issues will be marked N/A:

• Copy-pasting reports from another site or submitting reports, without providing any evidence that the vulnerability actually exists.
• Issues for domains listed in Out-of-scope domains section
• Issues mentioned under out-of-scope vulnerabilities.

Scope

"Typical" web vulnerabilities are generally considered in-scope. This includes, but is not limited to:

• Remote Code Execution (RCE)
• Cross Site Scripting (XSS)
• Cross Site Request Forgery (CSRF)
• Privilege Escalation
• Session Hijacking
• Leaking of sensitive customer data (especially anything in the scope of PCI)

Scope Exclusions

Only software-based issues are eligible for reward, things such as physical attacks against our offices or data centers do not qualify, nor do social engineering attacks. Protocols or standards not developed by WePay are similarly excluded, as are "non-optimal" protocol settings (e.g., RC4, SSLv3) unless said settings are directly exploitable. If in doubt please report it :)

Out-of-scope domains include, but are not limited to:

• e.wepay.com (Marketo )
• status.wepay.com (StatusPage.io )
• support.wepay.com (Zendesk )
• t.wepay.com (ThreatMetrix )
• visit.wepay.com (Marketo )
• blog.wepay.com
• doyouplatform.com

Out of scope vulnerabilities include but are not limited to:

• Issues related to software not under WePay's control
• Reports from automated web vulnerability scanners that are not validated.
• Issues that need social engineering for successful exploitation.
• Any physical attempts against WePay property or data centers
• Social engineering attacks against WePay employees
• Missing autocomplete attributes.
• Missing security flags on non-security-sensitive cookies.
• Username or Email enumeration.
• Missing Best practices.
• Spamming
• Issues that require physical access to a victim’s computer for successful exploitation.
• Open ports without an accompanying proof-of-concept demonstrating vulnerability.
• XSS issues that affect only outdated browsers.
• Tab nabbing and window.opener-related issues.
• Issues related to absence of CAA DNS record.
• Discrepancy related to permissions for owner and moderator role.
• Phishing using Open Redirection. Exceptions: Open redirection that leads to leakage of OAuth Access Token, bypass of Content Security Policy,etc.
• Content Injection issues
• CSV Injection. Please see this article
• Banner grabbing issues (Finding info like webserver name, etc.)
• Cross-site Request Forgery (CSRF) with minimal security implications like Logout CSRF
• Issues related to SPF,DKIM, and DMARC
• Reflected File Download
• Error Stack Trace or 401/403/500 Server error without an accompanying evidence of vulnerability
• Self-XSS including cases where user himself pastes javascript code into the browser.
• Issues without clearly identified security impact, such as clickjacking on a static website, descriptive error messages, HTTP OPTIONS method enabled, etc.
• Issues related to Payment Fraud.

Following findings are not eligible for bounty

• Issues related to Mixed Content
• Error Stack Trace or 401/403/500 Server error without an accompanying evidence of vulnerability

However, in case we decide to fix above issues, hackerone reputation points will be awarded.

Our SDKs are also ineligible for reward, as is other software open-sourced by WePay (such as that found on https://github.com/wepay ).

Too many duplicates have been filed and we will reject all new reports out- of-hand as N/A

• Clickjacking (we're actively working on this)
• Brute Force protection on login page

Rewards

Only security vulnerabilities qualify for rewards, which start at $100 and will increase based on severity and scope. Reports of non-security issues are appreciated, but will not qualify for a reward and will be marked informative. WePay's security team reserves final judgment regarding rewards.

While we certainly appreciate reports of a possible issue, the lack of a functioning exploit against the possible vulnerability means that most of these reports will not be eligible for a bounty. If we determine that your report is exceptional and is bounty-worthy, it will be paid-out from the bottom-end of the reward scale.

Automated Scanning

If you employ automated scanning tools, their requests must be rate limited to not exceed 3 requests per second without prior approval. Failure to do so may be considered a DoS attack and will result in disqualification from the program.

Automated vulnerability scanners commonly have low priority issues and/or false positives. Before submitting the results from a scanner, please take a moment to confirm that the reported issues are actually valid and exploitable. Please submit an issue only if you have exploited a real vulnerability.

Eligibility and Responsible Disclosure

You will qualify for bounty eligibility only if you are the first person to responsibly disclose an unknown issue. We intend to respond and resolve reported issues as quickly as possible, but please allow up to 14 days for a response and 90–120 days for a resolution (if we expect resolution to take longer, we will be upfront about this).

Issues not disclosed through HackerOne or by directly emailing security@wepay.com are ineligible and may result in removal from the program.

Tools

Zero members of our staff use Microsoft Windows, so videos which use Windows- specific tools are not helpful for reproducing issues. Videos should contain steps that can be reproduced without leveraging features that are specific to a single tool that is only available for Microsoft Windows.

We use Linux or OS X for everything. If your functioning exploit leverages a command-line tool, it should be a tool which works on OS X (Darwin), RedHat- based Linuxes (e.g., RHEL, CentOS) or Debian-based Linuxes (e.g., Debian, Ubuntu). If your functioning exploit leverages a GUI tool, it should be a tool which works on OS X.

Videos

Please use modern codecs and containers when submitting videos.

• H.264 video + AAC audio + MP4 container is overwhelmingly preferred.
• Non-Standardized codecs and containers (e.g., VP8, VP9, MKV, WebM, Ogg) are not preferred, but still acceptable.
• Outdated codecs and containers (e.g., Microsoft Video 1, VC-1, AVI, WMV, FLV, H.263, Theora, VP6, VP7) is discouraged.