Rate this page:
This page provides additional information on the security requirements for cloud apps. For each requirement, we have provided information on the reasoning behind the requirement and, where possible, how a Marketplace Partner can test if their applications meet that requirement.
All HTTP traffic is unencrypted by default, making it susceptible to eavesdropping and tampering. In order to ensure the security of data in transit, your application must use the Transport Layer Security (TLS) protocol. TLS provides a number of security benefits, including:
For a list of recommended ciphers , refer to Modern and Intermediate compatiblity cipher recommendations in Mozilla wiki
In addition, your application must implement the HTTP Strict Transport Security (HSTS) response header. HSTS ensures that a website can only be accessed using HTTPS and also prevents click through prompts on browsers.
There are several tools that enable you to validate your TLS configuration, including Qualys SSL Labs and SSLyze.
We recommend that you use TLS version 1.2 or above, as earlier versions of TLS and the SSL protocol have significant security vulnerabilities.
To verify that your application correctly implements HSTS, look for this response header:
1
Strict-Transport-Security: max-age=31536000; includeSubDomainsBrowsers can cache information to improve performance. While there are performance benefits to browser caching, it may store sensitive data that can be retrieved by examining the browser's cache or navigating back a page. Therefore, pages that contain sensitive data must have the Cache-Control header enabled with the values no-cache and no-store instead of private.
For each page that serves sensitive data, examine the request headers and make sure that Cache-Control header is configured as follows:
1 2
HTTP/1.1:
Cache-Control: no-cache, no-storeThe domain where your app is hosted as specified in the app descriptor file (atlassian-connect.json). The domain where your app descriptor file is hosted serves as the source for app descriptor updates for Atlassian.
When a domain expires, it can be claimed by an attacker who can then host a malicious app under that domain. However, users who have not reinstalled the app will continue to communicate with the old domain enabling the attacker to serve malicious content to users.
TLS certificates are issued by a trusted Certificate Authority and accepted by major browsers. When a TLS certificate expires, browsers will start warning and blocking the use of your application. An attacker will, however, be able to generate self-signed certificates for your domain and launch man-in-the-middle attacks against your application users.
Make sure that your domains supporting the application are valid and up to date by checking the “Domain expiration date” in your domain’s WHOIS records. Enable auto-renewal on your domains to avoid expiration, where possible.
Tools that validate your TLS configuration, including Qualys SSL Labs and SSLyze, provide information on the validity of TLS certificates. Ensure your TLS certificates are signed by a Certificate Authority trusted by the major browsers and they are valid. Enable auto-renewal of TLS certificates, where possible.
Subdomain takeover is a vulnerability that occurs when a domain or subdomain CNAME is pointing to a service (for example, GitHub pages or Heroku) that has been removed or deleted. This enables an attacker to serve content on the unused or dangling subdomain by setting up an account on the third-party service and claiming the subdomain.
Marketplace app domains are rarely exposed to users directly. However, a subdomain takeover vulnerability is an issue as it provides for the bypass of security policies and access controls. Also, there might be an implicit trust between the dangling subdomain and the application (for example, Javascript from the dangling subdomain).
Check your organization's DNS to make sure there are no dangling subdomains. You can also do a fingerprint scan on the services you’re using. There are commercial tools such, as Detectify, and open-source tools, such as subjack and tko-subs, that help identify subdomain takeovers.
Authentication is the process of determining that a user is who they claim to be, while authorization ensures that a user is allowed to access certain data or perform a specific operation within an app. Lack of authentication and authorization in applications can lead to vulnerabilities such as information disclosure, privilege escalation, authentication bypass, and others.
Authentication and authorization vulnerabilities are not easily detected by automated scanners, so we recommend using manual techniques to find them.
To test for authentication, send a request to each of your application’s endpoints without having an established session. If the endpoint returns data that should be protected by an authentication mechanism or enables you to perform sensitive state-changing action, then your application is vulnerable.
Similarly, when checking for authorization flaws or missing access controls, perform a request attempting to access or modify one user’s data while authenticated as another user. Be sure to test this for accounts with similar roles (horizontal authorization) as well as across different roles, for example, a low-level user to admin (vertical authorization).
In addition to making sure that proper controls are in place to protect application endpoints, it is important that data stored by the application is protected as well. Lack of proper authentication and access controls could result in the exfiltration of your data.
Testing will depend on how your data is stored. For example, if you are using S3 buckets, make sure you’ve configured the correct permissions and use a tool, such as S3Inspector, to check whether your buckets are public.
If your Connect app’s sharedSecret was exposed an attacker can impersonate your app, so proper security measures must be implemented to secure it. The sharedSecret should be encrypted and stored on the app server-side and only used during the JWT verification process.
A manual audit must be completed to identify where the sharedSecret is being used to ensure that it's not being leaked by unintended API endpoints or other functionality of your Connect app or infrastructure.
Exposing sensitive tokens such as JWTs, OAuth tokens, and client secrets in unintended places can lead to account takeovers and user impersonation attacks. These values must be stored securely and only used for their intended purpose.
A vulnerability scanner, such as Burpsuite, can help identify whether sensitive tokens are leaking to third-parties through the Referer header. There are also open-source tools, such as gitleaks, that can help identify whether source code repositories contain tokens. Consider implementing git-secrets or a similar tool in your development environment to prevent sensitive tokens being committed.
If the JWT token is not validated correctly by the app server, an attacker could trick the server in to process a malicious JWT token and then steal information accessible to legitimate users.
Details on how to correctly validate a JWT token can be found in the Validating incoming requests section of the Authentication for Connect apps page.
Burpsuite, a vulnerability scanner, can track outgoing requests from the web browser. Then use the JSON Web Token Attacker plugin, from the BApp Store, to change fields such as Alg and Signature in the outgoing JWT token. Requests with a manipulated token should not be processed by the server, confirming that the server is validating the JWT token.
A connect app should not collect or ask for Atlassian user credentials. Connect apps should use the JWT-based authentication provided by the Connect framework.
A vulnerability scanner. such as Burpsuite can flag any Atlassian user credentials being transmitted or stored in plain text. A manual audit of the source code must also be completed to ensure that Atlassian user credentials are not collected or stored by the app.
HttpOnly is an optional Set-Cookie HTTP response header flag. If supported by the browser, using HttpOnly when generating a cookie mitigate the risk of a client-side script accessing the protected cookie. If a browser that supports HttpOnly detects a cookie containing HttpOnly, and client-side script code attempts to read the cookie, the browser returns an empty string. This causes the attack to fail, by preventing the malicious (usually XSS) code from sending the data to an attacker's website
The Secure attribute tells the browser to only send the cookie if the request is being sent over a secure channel such as HTTPS. This protects the cookie from being passed over unencrypted requests. If the application can be accessed over both HTTP and HTTPS, then there is the potential that the cookie can be sent in plain text.
A vulnerability scanner, such as Qualys, Nexpose, or Burpsuite, can detect the absence of these flags.
If the appropriate Referrer-Policy header is not set it can lead to sensitive tokens leaking in GET URLs, including the query string, to third-parties through the Referer header.
Here’s an example both with and without the header which shows the impact of this issue.
Request for an asset without a Referrer-Policy Header set:
1 2 3 4 5 6 7 8
GET /js/addon.js HTTP/1.1
Host: matt-test-host-js.ngrok.io
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:76.0) Gecko/20100101 Firefox/76.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: close
Referer: https://matt-test-connect2.ngrok.io/xss-testing?xdm_e=... snip ... &jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.<redacted>Request for an asset with the Referrer-Policy Header set:
1 2 3 4 5 6 7 8
GET /js/addon.js HTTP/1.1
Host: matt-test-host-js.ngrok.io
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:76.0) Gecko/20100101 Firefox/76.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: close
Referer: https://matt-test-connect2.ngrok.ioNote: The above example sets the referrer-policy as Referrer-Policy: origin, so the origin will always be returned in the referrer header.
Atlassian Connect Express
You can add this header to your app universally by adding the following code into your main app.js:
1 2 3 4 5
// Set no-referrer header on all requests
app.use(function(req, res, next) {
res.setHeader("Referrer-Policy", "origin");
return next();
});Atlassian-Connect-Spring-Boot
Ensure you are using version 2.0.7 or later within your pom.xml
1
<atlassian-connect-spring-boot.version>2.0.7</atlassian-connect-spring-boot.version>Other Frameworks
If you are not using either of the above frameworks, you should ensure that the Referrer-Policy header is set in all of your responses.
The recommended directives are:
originstrict-originno-referrerScan your site using https://securityheaders.com/ to determine whether you have the Referrer-Policy implemented.
qsh is a custom Atlassian claim that prevents URL tampering by taking a SHA-256 hash of the original request's HTTP method, resource URI, and query string. By calculating the qsh in your application for requests received and comparing that to the qsh sent in the validated signed JWT token, you can guarantee that the URL has not been tampered with.
To test this make a request with a JWT token, modify the query string, and check that the request fails.
When using third-party libraries or dependencies in your application, you may be at risk due to vulnerabilities in those components. While some vulnerabilities reported in the third-party libraries may not affect your application, there are several reasons for this requirement:
Use scanners, such as retire.js or OWASP dependency check, or third-party tools, such as Snyk or sourceclear, to detect vulnerable or deprecated components. We recommend that you use the latest stable version of any library to minimize the risk of exploitation.
Atlassian makes it a priority to ensure that customers' data cannot be compromised by exploiting vulnerabilities in Atlassian products. This requirement extends that behavior to cloud applications. As Atlassian cannot have visibility on all your security vulnerabilities, we monitor for security SLA adherence and violations on vulnerabilities that we have reported to you through an app security incident ticket (DEVHELP) and the vulnerabilities that get reported to you through the Marketplace Bug Bounty Program.
See the Enforcement Procedure: Security Requirements for more information.
We provide you information on SLA due date and upcoming SLA violation through DEVHELP tickets. To achieve this requirement, ensure that you are aware of all vulnerabilities reported to your services.
Rate this page: