How to secure access to add-on properties

Jira Development Jira Cloud
1

Hello,

is it possible to secure access to add-on properties so that only selected users can set them using REST API? Project properties can be set only by project administrators, but unfortunately every logged in user can set add-on properties.

Our use case is that we use add-on properties in app descriptor to conditionally display some web panels, for example on our settings page we allow admins to always show a glance, so that our app will be visible in Jira mobile app. However, despite the fact that our app’s settings page is available to admins only every user can forge a request and set the add-on property. Is there any way to disallow such requests?

Alternatively, is there any other way to implement Jira-wide conditions, based on settings changeable by selected users, in add-on descriptor?

5 Likes
2

Hi @maciek,

You raise a valid issue. The storage APIs provided are limited, especially with respect to their protection from being read by different users. You should use a separate storage mechanism where you can fully control the access.

We are creating a guide on this topic at the moment.

Regards,
Dugald

4

Hello @dmorrow,

Thank you for chiming in.

But how to use this “separate storage mechanism” as a condition in Jira to show/hide panel for example? Add-on properties worked well for that use case.

Project properties are more secure but synchronising one global value to all projects seems like redundant and error prone solution.

Cheers,
Jack

5

Hi Dugald,

I would like to notice that Hosted Storage is used by quite a few Marketplace Partners, for similar cases, but with the Cloud Security Program in place, each of us gets same Security Bug, I guess.

You know we rely on Atlassian to make Hosted Storage secure, if this is possible.

Thank you.

6

Hi @AndriyZhdanov,

I think we are all in agreement that it makes sense for Atlassian to provide a solution. The development team is working on a solution that will be initially available for Forge apps, but later Connect apps also. Having said this, there could be a significant period of time before Connect apps can take advantage of this so I wouldn’t recommend holding off on any important fixes/changes.

Regards,
Dugald

2 Likes
7

Hi Dugald,

Sounds great, thank you very much for promise :slight_smile: may be you can share issue number also, for us to watch it?

Thank you.

2 Likes
8

From other hand, I think that it is not a security issue, assuming panel does not show any sensitive information, that unauthorized user would not be able to see otherwise.

E.g. we store in add-on properties who can see time tracking data, but this is solely in scope of our app, so that anyone can see time tracking data in Jira itself, disregarding this add-on config.

We declare this for customer, that we can not hide time tracking data in Jira.

So if malicious user wants, he does not need to hack add-on to see time tracking data.

Does it make sense?

9

@AndriyZhdanov

It is security issue if panel shows information that should not be visible to the user.

1 Like
10

@dmorrow The documentation on app properties REST API says:

Permissions required: Only a Connect app whose key matches addonKey can make this request.

The same requirement exists in dynamic modules REST API:

Permissions required: Only Connect apps can make this request.

In fact when I’m requesting dynamic module API from connect iframe, I get an error:

image
image970Ă—138 14.3 KB

On the other hand, app properties API does not work this way, it allows me to request this resource, even though I’m not a connect app.

Why App properties API is not following the documentation? I would expect to get the same error.

2 Likes
11

@Grzegorz.Tanczyk, they are going to fix it in Forge and leave Connect apps unprotected, unfortunately: https://community.developer.atlassian.com/t/the-dangers-of-entity-properties-in-confluence-and-jira/39990/41

There is existing feature request (it should be a bug of critical priority IMO): [ACJIRA-1730] - Ecosystem Jira

cc @mhart

1 Like
12

Well since I created ACJIRA-1730 - I want to point out that it’s different than fixing the lack of security that Atlassian discovered (and not fixing) and it. ACJIRA-1730 is about a single entity property(or properties) that can store encryption token etc.

1 Like
13

Why security bug fixes are treated as feature requests?

1 Like
14

I would like to echo the sentiments of others in this thread, that a fix for Connect apps should be given higher priority than it would seem to have been given by Atlassian.

I appreciate that the future is Forge, but there are are lot of existing Connect apps and the migration path from Connect to Forge is yet to be defined.

Here’s our story…

Last year we were fortunate to enough to achieve Silver Marketplace Partner status.
In February this year we were advised by the Marketplace Team that in order to maintain this status we were required to register the app with the most installs into the Marketplace Bug Bounty Program; which we dutifully did.

The first submission to our bug bounty program was received recently, and of course it was in relation to the App Properties REST API.

Our app (which is a Confluence dynamic content macro) includes an admin page - that is, our atlassian-connect.json descriptor file includes a configurePage property, which activates the “Configure” button for our app in the Manage Apps screen. The page is appropriately scoped to user_is_admin.

The configuration options that our admin page controls aren’t particularly sensitive (so exposing the values is not of any concern), but they do control how our app behaves so it would make sense to restrict who is allowed to update them, which the admin page does.

The admin page uses the App Properties REST API to store these settings under our apps key (/rest/atlassian-connect/1/addons/{app-key}/properties/config), and retrieved by the macro when it is rendered on a Confluence page.

The security researcher who submitted the bug report correctly noted that it is trivial for someone who is not an admin to issue a PUT request to the above endpoint and modify the settings, as the only restriction the API has is that a valid JWT for the Connect app must be provided (which any logged in user can easily obtain).

Naturally we paid the bounty on this bug report because it is a genuine security flaw in our app, but the fix for this will require us to migrate all existing customers settings out of app properties and store them in our own database.

Up until this point, we have (proudly) told our customers that we don’t store any of their data (aside from AddonSettings table that atlassian-connect-express maintains for installs), but this forces us to change this claim. Admittedly there is no PII data, but in the age of GDPR we want to hold as little data from our customers as possible.

I can’t for the life of me think of why a REST API endpoint that is able to mutate a shared setting (shared by all users of the app) would not at least have the option to restrict who is allowed to modify it.

We are obviously going to proceed with our migration away from app properties, as our customers expect that any settings controlled through the admin page are secure and not able to be tampered with. But we genuinely feel that this is a fundamental security issue that should be fixed in the platform rather than in every Connect app, as I’m sure we aren’t the first app to have paid out a bug bounty for this exact security flaw.

Atlassian have a duty to ensure that the APIs they offer are secure and fit for purpose, and we don’t believe the App Properties REST API currently is.

12 Likes
15

@scottohara, thank you for posting your story.

I’m only afraid that Atlassian won’t pay much attention to your wellbeing or the effort that you need to put into migration.

The even scarier scenario is when you use the add-on property in the descriptor condition. In that case, you have no choice but only to live with the vulnerability because moving data to the DB is not an option as you cannot use it in condition definition.

16

I am not 100% sure now, because when I was starting my first add-on it was more than 4 years ago. But I believe that I remember it correctly and I do remember that accessing app properties via AP.request back then was not possible - it worked according to documentation. This is reflected in my codes from that time. I even remember writing special REST endpoints just to change those properties by the app. 2 or 3 years later I have learned that this is no longer true and anyone can read and modify app properties. ( I want to emphasize that I am talking about app properties, not issue / other entities properties, entity properties were always not secured)

2 Likes
17

Did you find a workaround or solution to this problem?

18

Accepting the fact that Atlassian are unlikely to fix the poorly secured app properties API anytime soon, we ended up migrating from app properties into our own managed database (with all of the downsides previously mentioned…such as the fact that we can no longer, hand on heart, tell our customers that we don’t hold any of their data :slightly_frowning_face:).

The migration approach we took was effectively this (excuse the pseudo-code):

// First check if the customer data exists in our database
data = fetchDataFromOurOwnDb()

if (!data) {
  // If not, check if the customer data exists in app properties
  data = fetchDataFromAppProperties()

  // If so, copy the data from app properties into our database
  if (data) {
    saveDataToOurOwnDb()
  }
}

// Return the data
return data;