Magisto's Responsible Bug Disclosure Policy

Magisto engineers work hard to ensure that our site and users are 100% safe and sound. We greatly respect the work of security experts everywhere, and strive to stay up to date with the latest security techniques. But nobody's perfect. Should you encounter a security vulnerability in one of our products, we want to hear from you.

Before submitting a report, please review our guidelines below as to what constitutes a security vulnerability, and how we'd like you to go about finding them. Once you've filed a report, we promise to work expeditiously to evaluate and resolve any valid bugs.

Bounties are awarded based on merit at our discretion. After 3 medium or higher code based fixes, you can request to get a mention on our Bug Hall of Fame.

Public Disclosure Process and Policy

• Magisto reserves the right to approve or deny any request for disclosure.

• Magisto has a multi-level internal approval process for all valid disclosure requests.

• ONLY RESOLVED reports requested by the original reporter are eligible for disclosure (duplicate reports are not eligible).

• All other reports (Informative, NA, Spam) are not eligible for disclosure of any kind, in or outside the HackerOne platform. Failure to comply with these rules may result in a program ban for all company properties (Vimeo, Livestream, Magisto, VHX,) .

• Should a researcher break any disclosure or program policies, that researcher shall no longer be protected under Safe Harbor and will be subject to legal action at our discretion.

Scope Priorities and Disclaimer

Please read this section before submitting a report. We want to help reduce your chance of submitting an out-of-scope report that could hurt your Signal, as well as reduce noise in our inbox.

CODEBASE

Magisto regularly runs different codebases on servers accessible to the internet. Sometimes these are ahead of magisto.com, sometimes they are behind. As such, there is a high probability that an issue found on “A” would be on “B” and “C” but maybe not “D”.

The primary codebase you should be targeting is the magisto.com site. This is where the production systems are run, and therefore the ones most vulnerable. If we receive a report of a problem on magisto.com, it will not be closed until that fix is rolled out to all internet facing machines. Therefore, while the issue could be fixed on magisto.com on a Monday, it could be on “A” for up to another two weeks later. If you find one of the systems NOT patched after that two week period, then we will consider it a valid finding and can be reported. Otherwise, they will be marked duplicate to the magisto.com report.

Rules

• To be considered the original reporter of a vulnerability :

• You must be able to prove that there is a vulnerability using your own account(s) and your own data.

• Submit one vulnerability per report, unless you need to chain vulnerabilities to provide impact.

• Multiple vulnerabilities caused by one underlying issue will be awarded one bounty.

• Please provide detailed reports with reproducible steps.

• If the report is not detailed enough to reproduce the issue, the issue will not be eligible for a reward. Videos work best (No need to overlay music), Text with screenshots second, plain text last.

• HackerOne and Magisto must be able to reproduce it

• It must go to “TRIAGED” state and be paid the post triage acceptance bounty reward of $100

  (Reporting first without meeting the rest of the requirements or just having a lower ticket number does not qualify as being the original reporter. Please note we have an active security team that does scans, contracts out for pentests, developers fixing issues on their own, etc. While not in HackerOne they will count as being “first reporter”)

• Don't attempt to access other people's private data. Basic Magisto accounts are free, as well as the privacy features, so setting up example cases with throwaway accounts should be easy. Business accounts are available for a free trial. When you join, use the YEARLY Free trial during upgrade for one month of access (Monthly will only give 7 days). You are responsible for cancelling before it begins to bill.

• Don't use automated tools or scanners. Reports will be close as N/A.

• Don't DDoS or otherwise attack us in a way that would disrupt service for our customers

Qualifying vulnerabilities

Please take the time to provide a clear proof of concept that shows how a particular vulnerability is exploitable. You must be able to reproduce the issue on request with your account(s). Use the following guidelines to categorize security issues. (These are guidelines, the CVSS score will determine its ultimate rating)

Critical: most impactful, Remote code execution, SQLi, root access to any systems

High: IDOR requiring simple brute force on incrementing identifier, stored xss that can be used against logged in users, account authentication issues (bypass etc)

Medium: stored or reflected cross site scripting, other novel bugs that have a security impact to many users

Low: CSRF missing from non excluded functions, other security issues that impact only a small subset of users

Practical, chained vulnerabilities where the resource identifier is obtainable by a reproducible vector, e.g. guessable, predicable, or via API calls will be eligible for reward at Magisto discretion.

Wont fix: information disclosure, see also other non qualifying vulnerabilities

We do appreciate reports containing CVSSv3 formatted scores (https://www.first.org/cvss/calculator/3.0)

Reports from automated scanners will not be accepted.

We are primarily interested in exploits that could compromise user privacy or expose content in unintended ways that fit the rest of our rules and don't conflict with the non-qualifying vulnerabilities.

Non-qualifying vulnerabilities

Custom Header: X-MagistoBugBounty.

• Testing activity not using this header may be subject to rate-limiting, blocking, or potential exclusion from bounty eligibility. As our Magisto team is sensitive to testing-related performance and monitoring impact we'd also like to specifically call out automated content discovery and brute-forcing as out-of-scope.

• IDORs - Magisto has ongoing work for these known issues and we are currently not accepting reports at this time for this vulnerability type. IDOR's having unguessable/non-enumerable identifier are also out of scope.

• User enumeration

• Thumbnail / Description metadata leakage or similar

• Anything on `*.vimeo.com’ (Unless its is a Magisto<>Vimeo Integration or chained issue)- Otherwise these reports belong over at https://hackerone.com/vimeo

• Anything on `*.vhx.tv’ - these reports belong over at https://hackerone.com/vhx

• Anything on ott.vimeo.com - these reports belong over at https://hackerone.com/vhx

• Anything on livestream.com - these reports belong over at https://hackerone.com/livestream

• Reports from automated tools or scans

• Presence of autocomplete attribute on web forms

• Missing rate limits, unless it can lead to account takeover

• Missing cookie flags on non-sensitive cookies

• Logout CSRF attacks

• Reports of insecure SSL/TLS ciphers (unless you have a working proof of concept -- and not just a report from a scanner)

• Reports of insecure crossdomain.xml configuration (again, unless you have a working proof of concept -- and not just a report from a scanner)

• Reports of window.openerredirects

• Open SMTP redirects (just because it looks like you can use our servers doesn't mean its true-- unless you have a PoC)

• Email related attacks including spoofing or any issues related to SPF, DKIM or DMARC

• Missing security headers including (content security policy) which do not lead directly to a vulnerability

• Clickjacking on static websites

• Content spoofing / text injection

• Use of a known-vulnerable library (without evidence of exploitability)

• Vulnerabilities affecting users of outdated browsers or platforms

• Social engineering attacks including self-xss

• Homoglyph Attack, we feel this is a browser issue

• Missing HTTP security headers (unless you deliver a proof of concept that leverages their absence)

• Self-XSS (XSS exploits that cannot maliciously affect users besides yourself)

• Denial of service attacks, do not perform them

• 3rd party sites used by Magisto

• Subdomain takeovers where someone has signed up for an account, forwarded to an external site that doesn't exist/can be compromised

• RCE on sites that link or are redirected from Magisto

• Brute forcing

• Re-reports due to improper verification

• Issues where you would have to have access to the user's X (Phone, email, 2FA token, etc)

• Issues where the user's X (Phone, email, etc) have been rooted, malwared, bot'd, etc.

• Downloading or installing mobile versions from anywhere other than their associated official stores.

• If you are or have been banned on any Vimeo (/vimeo, /vhx, /livestream, /magisto) program

SLA

Magisto will make a best effort to meet the following SLAs for hackers participating in our program:

• Time to first response (from report submit) - 2 business days

• Time to triage (from report submit) - 2 business days (unless more information is needed from the hacker)

We’ll try to keep you informed about our progress throughout the process. We welcome cases where you've retested and find it has been fixed, as another ticket may have been the source.

Triage

Magisto is a HackerOne managed program. HackerOne currently has a 2 day commitment to initial triage. Once they do triage, they will pass it back to Magisto. Items in Triage state alone will NOT be considered accepted by the program until final disposition is made by Magisto, which will be denoted by an post triage acceptance bounty payout ($100). This initial payout will be deducted from the final bounty payout, if any. Tickets may be triaged by HackerOne, but later marked duplicate or other by Magisto. Where developers have already begun remedying the problem before ticket submission, triage, or even post triage acceptance bounty award are deemed to be ineligible for triage. (The can be self closed or marked duplicate with no links as the tickets will be in our internal ticket system).

Bounties/Bonuses

Past the initial post triage acceptance bounty award, an additional bounty/bonus/both, at our discretion, may be awarded at ticket completion. Only tickets that have been paid the post triage acceptance bounty award, have been picked up and worked by a developer and have been verified by the researcher are eligible to be put into a "RESOLVED" state signaling completion. Each ticket starts out at the bottom of a baseline range that takes into account initial perceived severity, as well as type. From there, it goes up (rarely down) given various factors (Including but not limited to: Actual final perceived severity, completeness of report, ease of working with the researcher, etc). All payouts are suggested by at least one person, approved by another.

Google Play Security Rewards Program

Certain vulnerabilities with a working proof of concept on some of our Android mobile app(s) may qualify for an additional bounty through the Google Play Security Rewards Program. To see which apps and vulnerabilities may qualify for a bounty, please refer to the Google Play Security Rewards Program’s Scope and Vulnerability Criteria.

Disclosure Policy

• Please do not discuss this program or any vulnerabilities (even resolved ones) outside of the program without express consent from the organization at any time.

• Follow HackerOne's disclosure guidelines.

Safe Harbor

Thank you for helping Vimeo, Inc. and its subsidiaries (“Vimeo”). Vimeo provides this Safe Harbor Statement to encourage and facilitate research using HackerOne’s bug bounty program to help us identify bugs and vulnerabilities.

We authorize to access our owned-and-operated systems, services, and applications for the purpose of conducting research consistent with HackerOne’s then-current policies. We will not consider your good faith activities in this regard to violate applicable criminal or civil laws (even if those activities inadvertently exceed the scope of our authorization), such as the Digital Millennium Copyright Act or Computer Fraud and Abuse Act, and we will not commence legal action with respect to such activities.

If legal action is commenced against you as a result of your good faith activities, Vimeo will take steps to make it known to parties commencing such action that your activities were conducted in accordance with this Safe Harbor Statement.

To the extent that our applicable online terms of service are inconsistent with this Safe Harbor Statement, then this Safe Harbor Statement shall control.

Please note that this Safe Harbor Statement does not extend to systems, services, and applications that we do not control.

We encourage you to contact us if you have questions regarding the scope of this Safe Harbor Statement. You may do so through HackerOne or by emailing us at bugbounty@vimeo.com.

*Thanks for helping us fight the good fight!