Requirement Yogi (Bug bounty)

Description

How to install Navigate to this checkout page Complete the form using an URL bugbounty-test-.atlassian.net and an email @bugcrowdninja.com , Go to Apps -> Find new apps -> Install "Requirement Yogi for Confluence" and "Requirement Yogi for Jira", Use an evaluation license (duration: 1 month), Checkout our Installation Checklist and our Getting started tutorials , More documentation We publish our OpenAPI files, see https://docs.requirementyogi.com/cloud/rest-apis, Our three main apps point to the same backend data: https://confluence.requirementyogi.com (the Confluence app's backend), https://jira.requirementyogi.com (the Jira app's backend), and https://app.requirementyogi.com (the standalone app). Definitions " Data " means the contents of requirements, usernames, emails, contents (including the title) of pages, contents (including the title) of issues, " Metadata " means the issue keys, requirement keys, space keys, space ids, page ids, names of categories, etc. " Long " means an integer with a length of 64 bits. Vulnerability ranking P1 - Theft of secrets, RCE Vulnerabilities that allow Remote Code Execution. Vulnerabilities that allow an attacker to impersonate the app to access data hosted by Atlassian without using our servers (e.g., Stealing secret tokens). P2 - Cross-tenant security Vulnerabilities that allow an attacker to view or edit Data belonging to another customer . Exclusion: Metadata , as defined in the "Definitions" section (downgraded as P4), Exclusion: Data access vulnerabilities that rely on brute-forcing a highly entropic UUID or Long are capped at P3, P3 - Same-tenant privilege escalation Vulnerabilities that allow a user to bypass the permission checks and view or edit the data of another user of the same customer. Exclusion: Page restrictions are not used in Requirement Yogi, only space permissions are used. Exclusion: Confluence/Jira permissions are cached for 30 minutes. Exclusion: Metadata , as defined in the "Definitions" section (downgraded as P4), Exclusion: Requirement keys are visible in Jira for any viewer of the issue, even if the user cannot view the requirement. Vulnerabilities that rely on brute-forcing a highly entropic UUID or Long, Vulnerabilities that allow an attacker to display false information to another customer. Example: A reflection vulnerability. Any other vulnerability that is ranked P3 or above on BugCrowd's taxonomy . P4 - Low Vulnerabilities on Metadata , Minor security flaws that affect singular users and require significant user interaction or specific prerequisites like a Man-in-the-Middle (MitM) position, Any vulnerability ranked P4 or above on BugCrowd's taxonomy . P5 - Informational / Non-Exploitable Any vulnerability ranked P5 or above on BugCrowd's taxonomy . Vulnerabilities that can't be immediately exploited, but pose a security risk in other circumstances. Exclusion: The contents of error messages. Note: These vulnerabilities will often be downgraded if we have already mitigated against this risk. Examples: Remote code execution which didn't succeed to access sensitive information, access to database credentials but the database is properly isolated in a private network. Rules, Exclusions, and Scopes Please only test using instances with the URL bugbounty-test-.atlassian.net . Please do not create additional instances outside of this namespace for testing. Do not test marketplace.atlassian.com, but install our apps and test the apps themselves. Do not post reviews for our apps on marketplace.atlassian.com. Failure to adhere to this will result in not receiving any reward for any of your submissions and possible removal from the program. Any domain/property of Requirement Yogi not listed in the targets section is strictly out of scope (for more information please see the out of scope and exclusions sections below). 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. Specifically for Requirement Yogi : Page-level restrictions are not applied. Requirements on a restricted page are visible to everyone in the space. Confluence administrators can always view all requirements, It is possible to change images inside of a requirement by pointing to a URL and swapping the image under the URL, Permissions (retrieved from Confluence or Jira) are cached for 30 minutes (as mentioned in P4), It is possible to view all requirement keys as a simple user with access to Confluence, but not their content. To help avoid grey areas, below are examples of what is considered out of scope. Blind XSS must not return any user data that you do not have access to (e.g. Screen shots, cookies that aren't owned by you, etc); when testing for blind XSS, please use the least invasive test possible (e.g. calling 1x1 image or nonexistent page on your webserver, etc). When testing, please exercise caution if injecting on any form that may be publicly visible - such as forums, etc. Before injection, please make sure your payload can be removed from the site. If it cannot be easily removed, please check with support@bugcrowd before performing the testing. No pivoting or post exploitation attacks (i.e. using a vulnerability to find another vulnerability) are allowed on this program. DO NOT under any circumstance leverage a finding to identify further issues. Any Requirement Yogi website is out of scope for this bounty unless it is a subdomain directly accessible from one of the targets or any associated services attached to the instance. Customer cloud instances and data are explicitly out of scope. Any repository that you are not an owner of - do not impact Requirement Yogi or Atlassian customers in any way. Only the latest version of our products are eligible for a reward. Any internal or development services. The following finding types are specifically excluded from the bounty: Lack of Rate Limiting on any of the targets. The use of high-volume, disruptive automated scanners is prohibited. If you use automated tools (like Burp Suite Active Scan), you must strictly rate-limit your requests to avoid degrading our service. Volumetric/DoS attacks will result in immediate removal from the program. Descriptive error messages (e.g. Stack Traces, application or server errors). Fingerprinting / banner disclosure on common/public services. Clickjacking and issues only exploitable through clickjacking. Logout Cross-Site Request Forgery (logout CSRF). Reflected Text Injection / Non-Persistent Content Spoofing (modifying text on a page via a URL parameter without XSS or persistent database changes). Presence of application or web browser ‘autocomplete’ or ‘save password’ functionality. Lack of Secure/HTTPOnly flags on non-sensitive Cookies. Lack of Security Speedbump when leaving the site. Weak Captcha / Captcha Bypass. Login or Forgot Password page brute force and account lockout not enforced. Username / email enumeration. Missing HTTP security headers, specifically ( https://owasp.org/www-project-secure-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. 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. Missing or incorrect DMARC 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. JWT in ajax requests ignores path and HTTP method. For some of our apps, we allow arbitrary HTML templates to be defined by administrators. Those could potentially be used for XSS attacks, however since only administrators have access we don't consider those as security threats. 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. Several similar reports which have the same root cause or can be resolved with the same bugfix will be counted as duplicates, 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 Requirement Yogi 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 Requirement Yogi offices, employees, equipment, etc. This bounty follows Bugcrowd’s standard disclosure terms. Public Disclosure Before disclosing an issue publicly we require that you first obtain consent from us. Requirement Yogi 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 Requirement Yogi's written consent will have any allocated bounty withdrawn and disqualified from the program. 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 used strictly during and for the purpose of your good-faith security testing; Exempt from restrictions in our Terms of Service 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. Third-Party Infrastructure: This Safe Harbor applies only to Requirement Yogi's code, domains, and data. We cannot bind Atlassian or any third-party hosting providers (e.g., AWS) to this Safe Harbor. Researchers must also adhere to Atlassian’s Acceptable Use Policy when interacting with .atlassian.net domains. 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. Thank you very much for your hard work.

Targets

How to install Navigate to this checkout page Complete the form using an URL bugbounty-test-.atlassian.net and an email @bugcrowdninja.com , Go to Apps -> Find new apps -> Install "Requirement Yogi for Confluence" and "Requirement Yogi for Jira", Use an evaluation license (duration: 1 month), Checkout our Installation Checklist and our Getting started tutorials , More documentation We publish our OpenAPI files, see https://docs.requirementyogi.com/cloud/rest-apis, Our three main apps point to the same backend data: https://confluence.requirementyogi.com (the Confluence app's backend), https://jira.requirementyogi.com (the Jira app's backend), and https://app.requirementyogi.com (the standalone app). Definitions " Data " means the contents of requirements, usernames, emails, contents (including the title) of pages, contents (including the title) of issues, " Metadata " means the issue keys, requirement keys, space keys, space ids, page ids, names of categories, etc. " Long " means an integer with a length of 64 bits. Vulnerability ranking P1 - Theft of secrets, RCE Vulnerabilities that allow Remote Code Execution. Vulnerabilities that allow an attacker to impersonate the app to access data hosted by Atlassian without using our servers (e.g., Stealing secret tokens). P2 - Cross-tenant security Vulnerabilities that allow an attacker to view or edit Data belonging to another customer . Exclusion: Metadata , as defined in the "Definitions" section (downgraded as P4), Exclusion: Data access vulnerabilities that rely on brute-forcing a highly entropic UUID or Long are capped at P3, P3 - Same-tenant privilege escalation Vulnerabilities that allow a user to bypass the permission checks and view or edit the data of another user of the same customer. Exclusion: Page restrictions are not used in Requirement Yogi, only space permissions are used. Exclusion: Confluence/Jira permissions are cached for 30 minutes. Exclusion: Metadata , as defined in the "Definitions" section (downgraded as P4), Exclusion: Requirement keys are visible in Jira for any viewer of the issue, even if the user cannot view the requirement. Vulnerabilities that rely on brute-forcing a highly entropic UUID or Long, Vulnerabilities that allow an attacker to display false information to another customer. Example: A reflection vulnerability. Any other vulnerability that is ranked P3 or above on BugCrowd's taxonomy . P4 - Low Vulnerabilities on Metadata , Minor security flaws that affect singular users and require significant user interaction or specific prerequisites like a Man-in-the-Middle (MitM) position, Any vulnerability ranked P4 or above on BugCrowd's taxonomy . P5 - Informational / Non-Exploitable Any vulnerability ranked P5 or above on BugCrowd's taxonomy . Vulnerabilities that can't be immediately exploited, but pose a security risk in other circumstances. Exclusion: The contents of error messages. Note: These vulnerabilities will often be downgraded if we have already mitigated against this risk. Examples: Remote code execution which didn't succeed to access sensitive information, access to database credentials but the database is properly isolated in a private network. Rules, Exclusions, and Scopes Please only test using instances with the URL bugbounty-test-.atlassian.net . Please do not create additional instances outside of this namespace for testing. Do not test marketplace.atlassian.com, but install our apps and test the apps themselves. Do not post reviews for our apps on marketplace.atlassian.com. Failure to adhere to this will result in not receiving any reward for any of your submissions and possible removal from the program. Any domain/property of Requirement Yogi not listed in the targets section is strictly out of scope (for more information please see the out of scope and exclusions sections below). 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. Specifically for Requirement Yogi : Page-level restrictions are not applied. Requirements on a restricted page are visible to everyone in the space. Confluence administrators can always view all requirements, It is possible to change images inside of a requirement by pointing to a URL and swapping the image under the URL, Permissions (retrieved from Confluence or Jira) are cached for 30 minutes (as mentioned in P4), It is possible to view all requirement keys as a simple user with access to Confluence, but not their content. To help avoid grey areas, below are examples of what is considered out of scope. Blind XSS must not return any user data that you do not have access to (e.g. Screen shots, cookies that aren't owned by you, etc); when testing for blind XSS, please use the least invasive test possible (e.g. calling 1x1 image or nonexistent page on your webserver, etc). When testing, please exercise caution if injecting on any form that may be publicly visible - such as forums, etc. Before injection, please make sure your payload can be removed from the site. If it cannot be easily removed, please check with support@bugcrowd before performing the testing. No pivoting or post exploitation attacks (i.e. using a vulnerability to find another vulnerability) are allowed on this program. DO NOT under any circumstance leverage a finding to identify further issues. Any Requirement Yogi website is out of scope for this bounty unless it is a subdomain directly accessible from one of the targets or any associated services attached to the instance. Customer cloud instances and data are explicitly out of scope. Any repository that you are not an owner of - do not impact Requirement Yogi or Atlassian customers in any way. Only the latest version of our products are eligible for a reward. Any internal or development services. The following finding types are specifically excluded from the bounty: Lack of Rate Limiting on any of the targets. The use of high-volume, disruptive automated scanners is prohibited. If you use automated tools (like Burp Suite Active Scan), you must strictly rate-limit your requests to avoid degrading our service. Volumetric/DoS attacks will result in immediate removal from the program. Descriptive error messages (e.g. Stack Traces, application or server errors). Fingerprinting / banner disclosure on common/public services. Clickjacking and issues only exploitable through clickjacking. Logout Cross-Site Request Forgery (logout CSRF). Reflected Text Injection / Non-Persistent Content Spoofing (modifying text on a page via a URL parameter without XSS or persistent database changes). Presence of application or web browser ‘autocomplete’ or ‘save password’ functionality. Lack of Secure/HTTPOnly flags on non-sensitive Cookies. Lack of Security Speedbump when leaving the site. Weak Captcha / Captcha Bypass. Login or Forgot Password page brute force and account lockout not enforced. Username / email enumeration. Missing HTTP security headers, specifically ( https://owasp.org/www-project-secure-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. 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. Missing or incorrect DMARC 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. JWT in ajax requests ignores path and HTTP method. For some of our apps, we allow arbitrary HTML templates to be defined by administrators. Those could potentially be used for XSS attacks, however since only administrators have access we don't consider those as security threats. 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. Several similar reports which have the same root cause or can be resolved with the same bugfix will be counted as duplicates, 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 Requirement Yogi 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 Requirement Yogi offices, employees, equipment, etc. This bounty follows Bugcrowd’s standard disclosure terms. Public Disclosure Before disclosing an issue publicly we require that you first obtain consent from us. Requirement Yogi 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 Requirement Yogi's written consent will have any allocated bounty withdrawn and disqualified from the program. 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 used strictly during and for the purpose of your good-faith security testing; Exempt from restrictions in our Terms of Service 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. Thank you very much for your hard work.