Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

BrizoIT is a team of Atlassian enthusiasts and who develop Atlassian apps. Our goal is to create apps that resolve real life business problems. We strive to provide exceptional customer support.

Info

The following findings are specifically excluded:

  • Access to exported calendar, including a private calendar (this is not a bug since the app was intended to share calendars with the public)

  • Testing privileges and REST services under admin accounts. Admins have rights to view, edit, and delete any data within their host Jira instance.

Note

Important! Theoretical assumptions and predictions will be ignored. We will only consider step-by-step scenarios that lead to concrete findings. Videos and screenshots are welcome.

Note: BrizoIT uses CVSS to consistently score security vulnerabilities. Where discrepancies between the VRT and CVSS score exist, BrizoIT will defer to the CVSS score to determine the priority.

Worth noting: Company Calendar for Jira is designed to help people visualize any dates from Jira issues. It's a calendar-based organizer. While you may submit findings, it must have a clear threat or business impact for users. Otherwise, it is likely to be marked as won't fix or informational.

In addition, please note that our applications cache some Jira entities for 15-minutes interval. For instance, ‌you, as admin, have removed an access to Jira from a user. The user will be able to interact with the application for up to 15 minutes, assuming there is a JWT token that was generated while the user was still granted an access to Jira.

Get Started (tl;dr version)

...

P5 submissions do not receive any rewards for this program.

Target information

...

Info

The following findings are specifically excluded:

  • Access to exported calendar, including a private calendar (this is not a bug since the app was intended to share calendars with the public)

  • Testing privileges and REST services under admin accounts. Admins have rights to view, edit, and delete any data within their host Jira instance.

Note

Important! Theoretical assumptions and predictions will be ignored. We will only consider step-by-step scenarios that lead to concrete findings. Videos and screenshots are welcome.

  • Note: BrizoIT uses CVSS to consistently score security vulnerabilities. Where discrepancies between the VRT and CVSS score exist, BrizoIT will defer to the CVSS score to determine the priority.

Worth noting, Company Calendar Planner for Jira is designed to help people visualize any dates from Jira issues. It's a calendar-based organizer. While you may submit findings, it must have a clear threat or business impact for users; otherwise, it is likely to be marked as won't fix or informational.

Rules, Exclusions, and Scopes

...

  • Lack of Rate Limiting on any of the targets.

  • 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.

  • 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.

  • 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/IE7IE11"). 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.

...