Security concerns in atlassian-connect

Jira Development Jira Cloud
, , , ,
1

Hello community,
I use the atlassian-connect-spring-boot to build my addon.
As I read in the documentation when the first installed lifecycle event happens, the shared secret token is sent and saved to the addon’s database to validate later requests.
However, since the POST request of the installed is unauthorized, a remote user can send an unauthenticated post request and this post request will be saved to the DB(our database under atlassianhost table (created by the framework).
For example, I used Postman to send the following request:

{
  "key": "ac.ci.4c9b3f61-1061-47cb-b04b-3a90e35b9bf2",
  "clientKey": "11e07151-ee7a-3139-b32e8-cd9de3957z43",
  "publicKey": "ExampleKey",
  "sharedSecret": "ExampleKey",
  "serverVersion": "100157",
  "pluginsVersion": "1001.0.0.SNAPSHOT",
  "baseUrl": "https://ofirtest3.atlassian.net", 
  "productType": "jira",
  "description": "Atlassian JIRA at https://team-1600938579211.atlassian.net ",
  "eventType": "installed"
}

All this information saved to the DB.
What can prevent external user to send such false installation requests and flood the database?

2

If I got it right and you’re using atlassian-connect-express, then verifyInstallation method in default ‘/installed’ behavior should resolve the issue you’ve mentioned: it will try to check if the registration is valid.

Otherwise, if you’re using your own implementation, you need to check this on your own.

3

Sorry I didn’t mention it, I use atlassian-connect-spring-boot ,
The installedImpl method does not verify if the registration is valid.

4

In case anyone else finds this post, and is not using atlassian-connect-spring-boot (which I have no experience with)

This has been discussed in the community before - at least in the context of vendors who are not using atlassian-connect-spring-boot.

Some ideas people are using:

  • verify that the installation request is coming from Atlassian IP range: https://ip-ranges.atlassian.com/
  • verify that a JWT generated from the shared secret can make a successful authenticated request to the host. (Note if you use this method, you must also verify that the host is an Atlassian.net, atlassian.com, or jira.com) domain.

See here for a previous discussion on the topic: Jira Connect App Installation handshake - Security Context

5

I do use atlassian-connect-spring-boot with the latest version (2.1.4)
However, I do afraid to upload my addon to production since the framework does allow to save
any POST request to the atlassianhost table through the /installed callback.
If there is a workaround to avoid saving false requests, please let me know.

6

@OfirNir We recognize this is a concern and we are working on an update to the app installation process whereby the initial install can be verified as coming from Atlassian.

We will use the apiMigrations mechanism we have used for other changes (e.g. GDPR, qsh, etc) to allow apps to opt into these changes during a transition period prior to full rollout.

3 Likes
7

@cmacneill The issue is still present in Atlassian Connect Spring Boot v2.1.5,
Any estimation when it will be solved?

8

@OfirNir App signed installs is being worked on and tested at the moment. I don’t have a hard timeframe to give you at present. I would expect it in June.

There will be an announcement made here when it is available for apps to opt in.

The focus of this announcement is the query string hash changes.