Statuspage

Description

Statuspage launched in 2013 to give companies a better way to be more transparent with their customers. We recognize managing a status page outside of one’s own infrastructure can be a hassle, and hope to increase the transparency of the web by making it easier to do so. Before you begin, please read and understand the Standard Disclosure Terms . Below is a list of some of the vulnerability classes that we are seeking reports for: Server-side Remote Code Execution (RCE) Server-Side Request Forgery (SSRF) Stored/Reflected Cross-site Scripting (XSS) Cross-site Request Forgery (CSRF) SQL Injection (SQLi) XML External Entity Attacks (XXE) Access Control Vulnerabilities (Insecure Direct Object Reference issues, etc) Path/Directory Traversal Issues Ensure you review the out of scope and exclusions list for further details. 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. Disclosure Request Guidance Submissions that meet the following requirements will be considered for disclosure upon request: The submission has been accepted The reported vulnerability has been fixed and released in production The submission does not regard a customer instance or a customer’s account

Targets

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 segment.io Out-of-Scope Anything not declared as a target or in scope above should be considered out of scope for the purposes of this bug bounty. 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 HTML injection. This is a feature of Statuspage templates, and is supported by the product. The exception is if the HTML injection leads to an XSS (other than self-xss). Then it is deemed in scope (see the section below about XSS for more details). CSV Injection 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, privilege escalation, 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. Sufficiently similar access control issues should be grouped in one report. Atlassian defines “sufficiently similar” as issues that use the same configuration for bypassing a particular control, which may be used on multiple related vulnerable endpoints or actions (User X can Create/Delete/Edit Resource Y). 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. 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. Reporting Guidelines Where applicable, please include the following information. This will greatly assist in the triage, validation, and acceptance processes and will result in more clear security risk communication and timely report acceptances. Brief summary (please include product versions affected/tested) Prerequisites (including any products, user privileges, tools required, files prepared, web server configurations, or any other initial conditions to prior to initiating the proof of concept) Reproduction steps including vulnerable endpoints, parameters, payloads used, source of any scripts used, or command line inputs (burp requests, screenshots and recordings are highly encouraged) Expected results/behavior vs actual results/behavior (include any formal documentation, resources, or links that state the expected behavior) Assessed security impact (as it relates to the Confidentiality, Integrity, and/or Availability of the product) Possible mitigations, fixes, or security controls Public Disclosure At Atlassian, one of our values is Open Company, No Bullshit, we believe that vulnerability disclosure is a part of that value. We hold ourselves to the security bug fix service level objectives, found here , and will accept disclosure requests in the bug bounty program after the issue has been fixed and released in production. However, if the report contains any information regarding a customer instance or data the request will be rejected. If you are planning to disclose outside of the bug bounty, we ask that you give us reasonable notice and wait until the associated SLO has passed. Safe Harbor When conducting vulnerability research according to this policy, we consider this research to be: Authorized in accordance with the Computer Fraud and Abuse Act (CFAA) (and/or similar state laws), and we will not initiate or support legal action against you for accidental, good faith violations of this policy; Exempt from the Digital Millennium Copyright Act (DMCA), and we will not bring a claim against you for circumvention of technology controls; Exempt from restrictions in our Terms & Conditions that would interfere with conducting security research, and we waive those restrictions on a limited basis for work done under this policy; and Lawful, helpful to the overall security of the Internet, and conducted in good faith. You are expected, as always, to comply with all applicable laws. If at any time you have concerns or are uncertain whether your security research is consistent with this policy, please submit a report through one of our Official Channels before going any further.