Asana

Description

No technology is perfect and Asana believes that working with skilled security researchers across the globe is crucial in identifying weaknesses in any technology. We are excited for you to participate as a security researcher in order to identify weaknesses. If you believe you've found a security issue, we encourage you to notify us. We welcome working with you to resolve the issue promptly. Ratings/Rewards: 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. Likelihood = How likely this particular vulnerability is to be uncovered and exploited by an attacker? Impact = Technical impact + Business impact. The first is the “technical impact” on the application, the data it uses, and the functions it provides. The other is the “business impact” on the business and company operating the application. See OWASP methodology for risk rating as a reference. Asana uses a nonce based CSP policy. If you discover an XSS vulnerability that you cannot exploit due to the CSP policy, but would at least be a P4 without the CSP policy present, we will reward that vulnerability as if it was a P4. Please also include the following information in your submission (if applicable): Domain Type (organization/workspace) Domain ID(s) used Domain Tier (free/premium/business/enterprise) Attacker membership level(s) Victim membership level(s) Security Impact Emails of accounts used for testing Special note on prompt injection We will consider submissions of this type if you can manipulate AI to have a measurable security impact to Asana, not just manipulating the AI model.

Targets

Target Information: Asana helps teams organize and manage all their work in the form of different projects. Please refer to the credentials section to understand how to sign up and go through the onboarding workflow to create one such project/workspace. Permissions overview https://help.asana.com/hc/en-us/articles/17826920767259-Permissions-overview Help articles https://help.asana.com/hc/en-us/sections/14005484724635-Permissions https://help.asana.com/hc/en-us Developer Documentation https://developers.asana.com/docs API Documentation https://developers.asana.com/docs https://developers.asana.com/docs/app-components Asana Academy https://academy.asana.com/ Other helpful resources https://help.asana.com/hc/en-us/articles/14075208738587-Premium-Business-and-Enterprise-authentication https://help.asana.com/hc/en-us/articles/14139896860955-Privacy-and-security https://asana.com/features/admin-security/admin-console https://asana.com/product/ai https://help.asana.com/s/article/ai-studio Credentials: Please self sign up for a free account using your @bugcrowdninja.com email address at https://asana.com/create-account . This process will automatically get you a free 30 day trial of Asana's Premium/Business accounts, without needing to input your credit card information. If you would like to continue using a premium account for testing after the trial ends, please create a new account using [email protected], etc. Out of Scope (PLEASE READ) assets.asana.biz Any testing involving making repetitive network requests. This includes testing for denial of service attacks and testing to see if rate limits are properly in place. Submitting any form on form.asana.com or form-beta.asana.biz that you did not create yourself. This includes submitting any customer survey hosted on those domains. Any Jira instance hosted on a subdomain of integrations.asana.plus. For example, jira-prod.integrations.asana.plus would be out of scope but foo.integrations.asana.plus would be in scope. If you find credentials, including but not limited to Asana logins, Okta logins, etc please report them but DO NOT attempt to log in. We will validate on our end. Submissions only containing leaked passwords, access tokens, etc will be accepted and rewarded with points only . Submissions only containing leaked documents, files etc will be accepted and rewarded with points only . Submissions only containing only broken links, or links pointing to unowned domains in documentation or static asana websites with no further impact will be accepted and rewarded with points only . 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. Security best practices without evidence of security impact or exploitation Weak login/signup without evidence of security impact or exploitation Weak password policy without demonstrated impact or exploitation Cookie issues without evidence of security impact or exploitation Lack of Secure/HTTPOnly flags on non-sensitive Cookies. Missing HTTP security headers, specifically https://www.owasp.org/index.php/List_of_useful_HTTP_headers Publicly-known zero-day vulnerabilities will not be considered for eligibility until more than 30 days have passed since patch availability Descriptive error messages (e.g. Stack Traces, application or server errors). EXIF data not being stripped from files or attachments. Attacks that aim to destroy or corrupt data not belonging to you. Attacks attempting to extend trial licenses. Intentional access to data or information not belonging to you beyond the minimum necessary to demonstrate the vulnerability. Do not access or manipulate data outside of domains that you control (including but not limited to customer data). Out of scope for Enterprise Technology targets: Clickjacking Broken link hijacking Firebase API key leakage without demonstrated impact Session expiration after logout Session timeout lengths or account lockout policies Failure to Invalidate Session on Password Reset Usage of components with known vulnerabilities without demonstrated security impact Business logic issues without demonstrated security impact Unrestricted file upload without demonstrated security impact Leakage/disclosure of Google Maps/MapBox API keys External service interaction without demonstrated security impact Password complexity and password length issues Post-based XSS without demonstrated security impact Blind SSRF without demonstrated security impact. Self-XSS without demonstrated security impact Cross-site request Forgery (CSRF) on unauthenticated forms or forms with no sensitive actions Attacks requiring MITM or physical access to a user's device. Previously known vulnerable libraries without a working Proof of Concept. Comma Separated Values (CSV) injection without demonstrating a vulnerability. Missing best practices in SSL/TLS configuration. Content spoofing and text injection issues without showing an attack vector/without being able to modify HTML/CSS Rate limiting or brute force issues Missing best practices in Content Security Policy. Missing HttpOnly or Secure flags on cookies Missing email best practices (Invalid, incomplete, or missing SPF/DKIM/DMARC records, etc.) Vulnerabilities only affecting users of outdated or unpatched browsers [Less than 2 stable versions behind the latest released stable version] Software version disclosure / Banner identification issues / Descriptive error messages or headers (e.g. stack traces, application or server errors). Public Zero-day vulnerabilities that have had an official patch for less than 1 month will be awarded on a case-by-case basis. Tabnabbing Issues that require unlikely user interaction HTML Injection without demonstrated security impact CRLF Injection without demonstrated security impact Reports from automated scanners Any activity that could lead to the disruption of our service (DDoS/DoS) Cache poisoning without demonstrated security impact Robots.txt or Sitemap.xml without demonstrated security impact Information Disclosure FrontPage Configuration Information without demonstrated security impact User/email enumeration Clear text password over HTTP without demonstrated security impact Dependency confusion EXIF Geolocation Data Not Stripped From Uploaded Images/Documents WordPress user's disclosure/enumeration Improper Cache-Control Enabled WordPress xmlrpc.php Open redirect without demonstrated security impact Focus Areas: Role Based Access Control Issues - Can a limited access member gain access to projects, areas of the app that they shouldn't have access to? Users permissions are gated by their effective access level. (i.e. Viewers should not be able to comment) Users should not be able to elevate their own access levels on an object. Asana as an OAuth provider ( https://app.asana.com/-/oauth_authorize ) OAuth vulnerabilities in integrations built into Asana Asana-made Integrations which can be found on this page App components used by some of our integrations Admin enforcements cannot be bypassed by internal DomainUsers. For example when domain is enterprise and is using SAML or GSSO required, we want to make sure all internal members of those domain cannot bypass admin's setting during login or signup. https://help.asana.com/hc/en-us/articles/14139896860955-Privacy-and-security https://asana.com/features/admin-security/admin-console Testing is only authorized on the targets listed as In-Scope. Any domain/property of Asana not listed in the targets section is out of scope. This includes any/all subdomains not listed above. If you happen to identify a security vulnerability on a target that is not in-scope, but that demonstrably belongs to Asana, it may be reported to this program, and is appreciated - but will ultimately be marked as ‘not applicable’ and will not be eligible for monetary or points-based compensation. 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 inquire via [email protected] before going any further.

Asana Targets (in scope)

The applications that access *.asana.plus can be found on the following page . Please note that only the apps made by Asana would be in scope.

Asana Enterprise Technology Scope (in scope)

Asana’s Enterprise Technology team welcomes responsible disclosure of impactful security issues. We are particularly interested in the following types of vulnerabilities: Remote Code Execution (RCE) Server-Side Request Forgery (SSRF) Path Traversal Local and Remote File Inclusion (LFI/RFI) Cross-Site Scripting (XSS) – excluding self-XSS Leakage of Personally Identifiable Information (PII) Security Misconfigurations – with clear security impact Additionally, we are interested in any vulnerabilities that enable threat actors to: Read arbitrary files / Execute system-level commands / Access sensitive or internal information not intended for public disclosure Notes: Valid subdomain takeover reports are welcome and will be accepted as P4 severity submissions, in line with our prioritization guidelines. Please make sure to review the Out of Scope section for Enterprise Technology targets before submitting your report to avoid any confusion.