Rate this page:
The Ecoscanner platform is a platform used for performing security checks against all Marketplace cloud apps on an ongoing basis. This will help us continuously monitor our Marketplace cloud apps for common security vulnerabilities and improve the overall security posture of our ecosystem.
We are focusing on Atlassian Connect app scanning first. Our goal is to slowly expand our scanning capabilities over the coming year. We will share these rollout dates as and when we have more clarity but for the immediate future, below are some rough dates of what to expect:
On November 23, 2020, we open sourced a tool called Connect Security Requirements Tester aka CSRT. This tool is built specifically to scan for missing security requirements.
Starting April 1, 2021, we will be scanning Marketplace apps for a subset of the Security Requirements.
Security requirement | Ecoscanner check | CVSS score | Details and remediation |
---|---|---|---|
1a | The application must use TLS to encrypt all of its traffic and TLS version 1.2 (or higher) are required. | 7.4 (High) | Transport Layer Security |
1b | HSTS must be enabled with a minimum age of at least one year. | 6.8 (Medium) | Transport Layer Security |
3 | For the domains where your app descriptor file is hosted and the domains specified (as the baseURL or other URLs) in the app descriptor file, TLS certificates of these domains must be valid | 8.1 (High) | Validity of Domain Registration & TLS Certificates |
A vulnerability within the Connect platform allows Connect Context JWTs tokens to be used in the place of server-to-server or iframe JWTs because of a missing qsh
claim.
The qsh
claim is designed to prevent replaying JWTs against other endpoints within apps (such as /installation lifecycle hooks). Because the qsh
is not present in context JWTs they can supplemented where server-to-server JWTs are expected to:
The impact of this vulnerability depends on what your app does. Your app is vulnerable if:
Because this is a vulnerability in the Connect platform/JWT spec, it’s highly likely your app is impacted.
qsh
bypassOur Ecoscanner utility checks if Connect apps are vulnerable to context jwt qsh
verification bypass by examining the app descriptor file for the following snippet:
1 2 3
"apiMigrations": {
"context-qsh": true
}
Apps containing this parameter are not vulnerable. In all other cases, a security vulnerability ticket will be raised against the app with the default severity of High (7.4).
As of March 22, 2021, Connect allows apps to opt into a static qsh
in context JWTs. To mitigate the vulnerability in your app, you must:
qsh
claim behavior by updating your apiMigrations Connect descriptor; andqsh
claims; andYour descriptor should look like:
1 2 3 4 5
...
"apiMigrations": {
"context-qsh": true
}
...
Marketplace apps with a registered domain that is expired can be re-registered by a malicious user and then used to exfiltrate sensitive information from any tenant where the vulnerable app is installed.
We check the app baseUrl
for domains that appear to be available for registration. For apps with expired domains, a security vulnerability ticket will be raised with the severity of Critical (9.0).
Domains for any app installed on a customer tenant must be owned and controlled by the developer of the app. Apps that are no longer maintained must be uninstalled from all customer instances.
All scanning activity originating from Ecoscanner is supposed to be non-intrusive and very basic so Atlassian will continue to scan the production environment of cloud apps for now. If this changes in the future, we will communicate accordingly.
All scan traffic should originate from the below listed IPs
1 2 3 4 5 6
100.25.61.160
3.214.98.112
35.172.132.4
3.221.51.2
3.217.215.43
35.174.235.12
Generally speaking, the more links in your descriptor, the more traffic you will receive. The traffic is very “bursty”. But, some approximate numbers are below:
Initial validation – Max 2 requests
Descriptor scan – Max 6 requests per link
TLS scan – No noticeable traffic at the app-level
As and when we introduce additional scanners, we will follow up with a CDAC post and also update this page. We will treat open sourcing on a case by case basis.
Yes, absolutely. We would totally love this. You come up with scanners and let us deal with figuring out how to run them at scale against all apps. Please feel free to create a request in ESSD describing the scanner and instructions on how to run it.
We will keep the scanner sections above updated with their scanning cadence
We will communicate the vulnerability reporting/notification once we have more information.
As of now, we are not planning to scan server and DC apps. This might change in the future as the Ecoscanner platform becomes more mature.
Apps CANNOT opt out of scanning at this time.
We hope this never happens since the scanning is going to be non-intrusive (unless otherwise mentioned). In the odd case when it does end up breaking your app and you want us to look into it, please go ahead and create a request on ESSD.
During our staged rollout, not all apps will be scanned. Once we have fully rolled out EcoScanner, every marketplace app will be scanned on a regular cadence as listed above. If you feel like your app is not being scanned, you are welcome to open a ticket with us to confirm at ESSD.
We understand it is not practically possible to scan for all the requirements (because of the subjective nature of them that is different for different apps) but there are a handful of requirements that we can scan for. We will NOT be reporting any security vulnerabilities right now. We are going to continuously monitor the platform for any improvements and fine tune it, if necessary. Once we are confident about the quality of findings, we will then begin reporting them as vulnerabilities. More information on this to come at a later date.
Rate this page: