Trello

Description

Trusted by millions, Trello is a visual collaboration tool that creates a shared perspective on any project. Trello’s boards, lists, and cards enable you to organize and prioritize your personal and work life in a fun, flexible, and rewarding way. Ratings/Rewards and Bounty Rules: For the initial prioritization/rating of findings, this program will use the Bugcrowd Vulnerability Rating Taxonomy . However, it is important to note that in some cases a vulnerability priority will be modified due to its likelihood or impact. In any instance where an issue is downgraded, a full, detailed explanation will be provided to the researcher - along with the opportunity to appeal, and make a case for a higher priority. Note: Atlassian uses CVSS to consistently score security vulnerabilities. Where discrepancies between the VRT and CVSS score exist, Atlassian will defer to the CVSS score to determine the priority. To qualify for a bounty you must: Report a qualifying vulnerability that is in the scope of our program (also below) Be the first person to report the vulnerability Adhere to our disclosure guidelines (see below) Only test against your own accounts and data Be reasonable with automated scanning methods so as to not degrade services Refrain from disclosing the vulnerability until we've addressed it Communicate with our security team exclusively via Bugcrowd (the security team will be way more impressed by your exploits than our support or social media teams) Access/Credentials You are free to make as many accounts as needed to test on Trello - please ensure that you use your @bugcrowdninja.com email address. 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

Reports must include the following: A Proof of Concept Detailed steps on how to reproduce the vulnerability Explanation of how the attack could be executed in a real world scenario to compromise user accounts or data Vulnerabilities affecting blog.trello.com will only qualify for a bounty if they include a working proof of concept showing how the issue can compromise user data on trello.com. Other domains (e.g. trello-attachments.s3.amazonaws.com) or subdomains not listed above (e.g. e.trello.com, help.trello.com) and 3rd party services, are not in scope and will not qualify for a bounty. Out-of-Scope Customer instances and data are explicitly out of scope. Any Board/Card/Data that you are not an owner of - do not impact Trello customers in any way. Any Trello billing system. However, specific endpoints that are used inside of a target are in scope. For example, if a REST endpoint is proven to be called from one of the targets, then that endpoint is considered to be in scope. However, all other endpoints are not considered to be in scope, as they are not called from the instance at any stage. Any internal or development services 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) Descriptive error messages (e.g. Stack Traces, application or server errors). HTTP 404 codes/pages or other HTTP non-200 codes/pages. Fingerprinting / banner disclosure on common/public services. Disclosure of known public files or directories, (e.g. robots.txt). Clickjacking and issues only exploitable through clickjacking. CSRF on forms that are available to anonymous users (e.g. the contact form). CSRF attacks that require knowledge of the CSRF token (e.g. attacks involving a local machine). Logout Cross-Site Request Forgery (logout CSRF). Content Spoofing. Presence of application or web browser ‘autocomplete’ or ‘save password’ functionality. Cookies missing secure/HttpOnly. Lack of Security Speedbump when leaving the site. Weak Captcha / Captcha Bypass. Login or Forgot Password page brute force and account lockout not enforced. OPTIONS HTTP method enabled. Username / email enumeration. Missing HTTP security headers, specifically (https://www.owasp.org/index.php/List_of_useful_HTTP_headers), e.g. Strict-Transport-Security. X-Frame-Options. X-XSS-Protection. X-Content-Type-Options. Content-Security-Policy, X-Content-Security-Policy, X-WebKit-CSP. Content-Security-Policy-Report-Only. Cache-Control and Pragma HTTP/DNS cache poisoning. SSL/TLS Issues, e.g. SSL Attacks such as BEAST, BREACH, Renegotiation attack. SSL Forward secrecy not enabled. SSL weak/insecure cipher suites. 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 an Atlassian 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. Email bombing Flooding Rate limiting CSV Injection Rules 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 and are only testing on instances that you own. 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 Atlassian 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 Trello offices, employees, equipment, etc. This bounty follows Bugcrowd’s standard disclosure terms. Scoring A few issue types are not scored by their CVSS scores These are typically higher severity, but will be rewarded as P4 issues: XSS Vulnerabilities where the script is blocked by the product's Content Security Policy, unless a bypass is documented as part of the submission Open Redirect bugs, and Broken Access Control or Privilege Escalation bugs, where an Administrator is able to perform System Administrator actions. ### 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. 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 References 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. Thanks We're happy to acknowledge security researchers that have helped us keep our users' data secure on our Hall of Fame page. https://bugcrowd.com/trello/hall-of-fame

Trello Third Party Powerups (in scope)

Note on Trello Third Party Powerups Trello Third Party Powerups are not officially under Atlassian ownership and do not follow the normal bug bounty security assessments. However, vulnerabilities found in Trello Third Party Powerups can be reported and we will make attempts to forward such reports to the creators of the Powerups. We do not guarantee the eligibility for a reward. Rewards may be considered on a case-by-case basis if the vulnerability can affect Trello customers outside of the third party powerup (e.g. a valid XSS attack that can steal the Trello token of victim users). Atlassian holds the right to eliminate rewards for third party powerups at any given time.