Security of Atlassian Connect add-ons

As we saw in the Introduction to Atlassian Connect , add-ons are stand-alone web applications, operated by different vendors. They communicate with the Atlassian application through the internet. Especially for enterprises this may raise questions about security and data protection. We will investigate on these aspects in this article without going too much into detail, but instead by showing how many points need to be considered.

We use JIRA as example, but the considerations can be applied to other Connect applications (Confluence, HipChat, BitBucket) as well.

Overview

In the following, we will examine four different areas, where security aspects are relevant. The image gives an overview to structure them.

We will focus on the following topics:

1. The communication between the Atlassian application and the add-on
2. The authorization concept of the Atlassian product
3. Requirements on the Connect add-on
4. Protection of private add-ons

Communication between the two applications

As described, both applications interact via public network, which requires protection of their communication. Data is sent through the internet and must not be manipulated or read by others. Therefore Connect is using two mechanisms to secure the communication: HTTPS and JWT.

Before giving a deeper insight into these mechanisms, we would like to give a short introduction into add-ons’ life cycle: A Connect add-on can provide webhooks. These webhooks are registered for different activities and application phases. During installation of the add-on, an exchange of security information takes place. This also includes a shared secret, which will be important later in this section.

For add-ons which should be listed in marketplace, secured communication with HTTPS is mandatory. This way, transmitted data is encrypted and cannot be read by unauthorized persons/programs. Encryption has to covers every kind of communication, including the installation of the add-on descriptor and especially the exchange of security information during installation.

Furthermore, JWT is used to sign messages, which offers an authentication mechanism. For every message, the originator can be validated. Therefore the formerly exchanged secret is used.

Requests to the JIRA REST API have always to be signed, or they will be treated like anonymous users, who have only minimal or even no permissions. By reading the signature, the application can infer the related user and can perform further security checks (see next section).

For every incoming message on the add-on, the signature should also be validated. The Atlassian application signs every message, but the responsibility to check this signature stays on add-on vendor’s site. Only if he verifies it, he can be sure that the request came from an authenticated partner. Atlassian supports the developer by providing libraries for the creation and validation of JWT tokens.

Permissions

Atlassian Connect supports granting of permissions on single add-ons. This is realized through an add-on-user, which can be configured like a normal user (but will not be accounted on the user budget of your license).

Permissions like “reading” and “writing” data can be specified in the add-on descriptor. These are called “scopes”. If the add-on wants to change data in the application, the write scope is required.

The requested scopes are shown during the installation process of the add-on and have to be confirmed by the administrator. This also applies to updates in case they require new scopes.

Security of the add-on

Now that we have seen how the communication and the access to the core application are protected, it’s time to have a look at the add-on application itself. Secure communication is no use if the add-on itself is completely vulnerable for attacks.

For vendors, it is mandatory to provide a “Data Security & Privacy Statement“ in the Marketplace listing. Atlassian has recommendations and guidelines on that, but the responsibility of implementation is on add-on vendor’s site. When storing data, add-ons should handle tenants’ data separately. The plugin instance can be used by different cloud instances of different customers, who must not access each other’s data. Of course, the storage itself has to be protected against access and manipulation by third parties.

This last point applies in general to the whole web application and the underlying system. As such an application can be built and operated in various ways, we can provide only very general hints for security here. There are some well known attack scenarios , following some basic principles. Recommendations to prevent such attacks exist and can be found in the linked pages.

Besides the protection from direct attacks, for users the availability and stability are also important factors. Unavailability of the add-on can limit or even block processes at the customer. Therefore, a continuous running add-on application is crucial for them. Even individually planned maintenance windows are nearly impossible, as the add-on can be used by different cloud instances of customers around the world, residing in different time zones. So again, the vendor has the responsibility to ensure this aspect of security/availability.

Another import point in this area is protection against loss of data, e.g. on hardware failures. So there is a need for backups and redundant systems.

Private add-ons in marketplace

For customers that want to write their own add-ons for internal use, Atlassian offers the possibility to list them as “private add-on” in the Marketplace. Additionally there are ways to bypass the marketplace completely. We will describe both options in the following section.

The add-on can be listed as “private” in Marketplace and is then visible only within the vendor’s organization. For the installation in JIRA a separate token is needed to make the add-on visible. Tokens can be managed on a separate page by the vendor. They are valid for a single JIRA instance.

To install the add-on, the administrator of the JIRA instance needs to explicitly allow integration of private add-ons. Afterwards, the installation can happen through marketplace with the token.

This first option produces some effort, but has the benefit of being the official way and offering some support by Atlassian, like monitoring of availability.

The second option is to include the plugin in development mode. This allows installation without registration in marketplace, but is not intended by Atlassian to be used for production usage. There is no automatic monitoring and a critical point is the missing transmission of license information which hinders the protection against unauthorized usage by third parties.

In conclusion there are two ways to include private add-ons in the cloud application. For mission critical processes, the official way with private marketplace listing is highly recommended. But for a fast and simple start, there is also the option to use the development mode.

Here we want to provide a last hint about publicity: Even if the name “private add-on” does not suggest this at first glance, these add-ons (their REST API) need to be publicly available through the internet like every other public add-on. So all the concepts discussed before apply also to these ‘private’ cloud add-ons.

Conclusion

As the article shows, there are many aspects that influence the security of a cloud add-on. One also needs to be aware of the fact, that server add-ons cannot be stated as secure in general. They can also contain huge security leaks and also hosting an own JIRA instance by a customer can bring its risks if he has no experience in doing so.

The question, if Connect add-ons are (more or less) secure, can not be answered in general. Atlassian supports the vendor by providing libraries and enforcing encrypted communication. There are also recommendations and the documentation of Connect contains a part about security. But the main responsibility remains in the hand of the add-on vendor. He has to consider many things and needs to handle them correctly, then the Connect add-ons can be seen as secure. The review by the user is very hard here, so in the end, the decision whether to trust a cloud add-on vendor or not remains a customer’s responsibility and a serious question.