Statuspage

Please read the note on XSS at the bottom of this bounty brief.

Any domain/property not listed in the targets section is strictly out of scope (for more information please see the out of scope and exclusions sections below).

Some third party hosts are also in scope. Any third party host will only qualify if the attack can exploit our customers directly. These third parties include:

• help.statuspage.io
• doers.statuspage.io
• filepicker.io
• customer.io
• segment.io

Accessing Statuspage

Please visit https://manage.statuspage.io/security-researcher to identify yourself as a security researcher, this will give you a free account for a month. You'll need to create an account and log in to view this page.

Out-of-Scope

Anything not declared as a target or in scope above should be considered out of scope for the purposes of this bugbounty. However for verbosity and to help avoid grey areas, below are examples of what is considered out of scope.

• The following targets are out of scope:
  • www.statuspage.io
  • metastatuspage.com
  • blog.statuspage.io
• Any widely-disclosed vulnerabilities in any public vendor components. For example Heartbleed or CCS affecting Amazon ELB.

The following finding types are specifically excluded from the bounty

• The use of Automated scanners is strictly prohibited (we have these tools too - don't even think about using them)
• No Load testing (DoS/DDoS etc) is allowed on the instance.
  • This includes application DoS as well as network DoS.
• Self-XSS reports will not be accepted.
  • Similarly, any XSS where local access is required (i.e. User-Agent Header injection) will not be accepted. The only exception will be if you can show a working off-path MiTM attack that will allow for the XSS to trigger.
• Vulnerabilities that are limited to unsupported browsers will not be accepted (i.e. "this exploit only works in IE6/IE7"). A list of supported browsers can be found here.
• Known vulnerabilities in used libraries, or the reports that a Statuspage product uses an outdated third party library (e.g. jQuery, Apache HttpComponents etc) unless you can prove exploitability.
• Missing or incorrect SPF records of any kind.
• Source code disclosure vulnerabilities.
• Information disclosure of non-confidential information (e. g. issue id, project id, commit hashes).
• The ability to upload/download viruses or malicious files to the platform.
• Password strength requirements
• Email bombing/Flooding/rate limiting

Rules

• The bug does not depend on any part of the Statuspage product being in a particular 3rd-party environment. In particular, we are not responsible for vulnerabilities on the sites of any of our customers that may happen to use Statuspage, unless those vulnerabilities might affect other Statuspage users or our main site. +The bug is an application vulnerability (database injection, public status page XSS, session hijacking, remote code execution and so forth) in our main website, the JavaScript widget, our API, any customer status page, or one of our other core services. +The bug cannot require extended user action to execute. For example, stored XSS must be present on a public status page, and cannot require user responding to a team member account invitation and then subsequently logging in to view the stored XSS page.
• The bug's effects are not limited only to browser/version combinations that cannot be conceivably called modern in any way -- we're looking at you, IE6/7.
• You are the original source of the bug through your own research, and you are the first person to report the particular vulnerability to us.
• You're not a minor, nor are you on any list of people we are not legally allowed to do business with.
• You must ensure that customer data is not affected in any way as a result of your testing. Please ensure you're being non-destructive whilst testing.
• In addition to above, customer instances are not to be accessed in any way (i.e. no customer data is accessed, customer credentials are not to be used or "verified")
  • If you believe you have found sensitive customer data (e.g., login credentials, API keys etc) or a way to access customer data (i.e. through a vulnerability) report it, but do not attempt to successfully validate if/that it works.
• Use of any automated tools/scanners is strictly prohibited and will lead to you being removed from the program (trust us, we have those tools too).
• Reports need to be submitted in plain text (associated pictures/videos are fine as long as they're in standard formats). Non-plain text reports (e.g. PDF, DOCX) will be asked to be resubmitted in plain text.
• Grants/awards are at the discretion of Statuspage and we withhold the right to grant, modify or deny grants. But we'll be fair about it.
• Tax implications of any payouts are the sole responsibility of the reporter.
• Do NOT conduct non-technical attacks such as social engineering, phishing or unauthorized access to infrastructure.
• Do NOT test the physical security of Statuspage offices, employees, equipment, etc.
• Please do not test our capacity, or for Denial of Service or similar exploits.
• Please do all testing on your own account, and do not impact our customers in any way.
• XSS attacks that require user submission ("reflective" XSS, as opposed to "stored" XSS), or self-XSS attacks, are not eligible for a reward or recognition.
• Stored XSS attacks must be viewable on a publicly hosted page residing on a *.statuspage.io subdomain. Any stored XSS attack that requires a user to sign up for an account as a team member, or appear on a CNAME domain, are not eligible for a reward or recognition.
  • Stored XSS as it relates to custom header/footer HTML will behave differently on a live status page. While pages are private, stored XSS is allowed for page setup purposes. See http://bitbucket.statuspage.io(CSS only) vs http://status.bitbucket.org (CSS & HTML) for a live example.

This program adheres to the Bugcrowd Vulnerability Rating Taxonomy for the prioritization of findings. However, Statuspage reserves the right to downgrade or upgrade a report's findings based on the criticality and impact of the report.

Public Disclosure

Before disclosing an issue publicly we require that you first request permission from us. Statuspage will process requests for public disclosure on a per report basis. Requests to publicly disclose an issue that has not yet been fixed for customers will be rejected. Any researcher found publicly disclosing reported vulnerabilities without Statuspage's written consent will have any allocated bounty withdrawn and disqualified from the program.