Feedback Request: Security Requirements for Cloud Apps

Announcements
, , , , ,
1

Hey, everyone! :grinning:

In the near future, Ecosystem Security is planning to publish an update to the security requirements for cloud apps, which fits into our overall goal of elevating trust in the marketplace. Some of you may have heard about this initiative already; we’ve recently shared a preview of these updates with developer community discussion groups, like this recent Atlassian Community Event.

To all of the developers who have provided feedback already - thank you .

We’ve incorporated those first rounds of feedback into a second draft , which is what we’d like to share with the community today. We know that security takes time, and that there are tons of use cases to consider, which is why these feedback rounds are important. We want to hear your thoughts and challenges in accomplishing these security goals.

For background, our requirements are essentially our security expectations for all apps in the marketplace. They intend to answer the question, “how do I develop a secure app for Atlassian?” We have not updated these requirements in a bit, but we’re hoping to update them on a regular cadence in the future to make sure we’re up-to-date with new bug bounty findings, industry trends, or other technological changes. We are currently thinking that cadence will be yearly.

Why are we doing this now? Well, for a few reasons:

  1. To increase the security baseline for all cloud apps, making the Marketplace more trustworthy for customers. We have heard – time and time again – that customers expect more from our cloud apps’ security at large, and we believe that these expectations are a critical step in building that trust.
  2. To give clarity on security requirements specific to the platform that you build on, whether it’s Connect, Forge, Forge with off-Atlassian services, or Trello Apps (Power-Ups). In the past, developers have had to figure out for themselves whether a security requirement applied to them, or whether their choice of development platform made them exempt. You’ll notice that these requirements are listed to the left of this table, and that the right columns outline specific implementation details based on the type of app. This is to help guide you in making your app secure based on your use case.

These new requirements are still a work in progress. Before we make them official, we want to gather the community’s input. Are some of these requirements impossible to implement given what’s available to you today? Is the language clear? Do you think you can be equally secure by doing something that’s not outlined in our implementation details? For these questions and any others, we want to hear from you.

We also want to know how long it’ll take you to implement requirements that you do not meet today. Feedback from you will be a factor in us determining when these new requirements go into effect.

If you have questions or if you have concerns - please let us know. Our goal is to bring in community feedback at an early point in this project so we can make sure new security guidelines reflect what’s best for both Atlassian customers and partners.

For feedback, you can either:

  • Email me directly at jcomito@atlassian.com
  • DM me on CDAC
  • Comment on this post if you think your comment is relevant to everyone
  • As always, if you need support in implementing a specific requirement, raise a DEVHELP ticket.

Feedback Request - Security Requirements for Cloud Apps.pdf (145.9 KB)

6 Likes
2

Very nice draft :slight_smile: :tada:

We are making forge apps with a “delegated administration” feature where we implement our own permission structure and the call asApp() after we have checked our own custom permissions if a user can perform a certain administrative task such as “add customfield option”.

Is this in line with your proposed security standards?

1 Like
3

@JakeComito may I suggest moving this post to a public topic? Is there a specific reason why this draft is considered non-disclosable?

1 Like
4

Question:

  1. An application must not collect or store credentials belonging to Atlassian
    user accounts such as user passwords or user API tokens.

We do ask users for an Atlassian API key, and use this API key to identify the user. This API key is not stored.

Is this kind of usage allowed under the new rules? I’m asking because our customers often like using Atlassian API keys, because they can be revoked within Atlassian, and are bound to an Atlassian account.

I believe in general, API keys are made to be stored and used by applications. Many apps outside of the Marketplace use Atlassian API keys to interact with e.g. Jira. I would expect that Marketplace apps could do the same. It would help if a user could give a specific scopes to an API key (unfortunately currently not possible).

5

It would be great to have both customer and security researcher definitions of:
“Connect,” “Forge with data egress,” “Forge,” and “Trello Apps (Power-Ups)"

This would let us explain to customer why other application types (such as standalone apps using oAuth).

1 Like
6

Just a bit nitpick here - but why is #10 (" An application must not collect or store credentials belonging to Atlassian user accounts such as user passwords or user API tokens.") under Privacy? Especially since the linked document doesn’t talk about user credentials.

7

For the Forge scopes - I’m a bit confused. The granular scopes is on hold according to Action required: Update scopes for Forge and OAuth 2.0 (3LO) apps - should those sections be removed?

1 Like
8

Done!

9
  1. An application must
    not use versions of
    third-party libraries
    and dependencies
    with known critical or
    high vulnerabilities.
    When vulnerabilities
    in these libraries and
    dependencies are
    discovered, an
    application owner
    must remediate them
    as quickly as possible.

This once more time brings up the question what should we do about Atlaskit libraries that are essential to the apps and are too complex to DIY for vendors, but Atlassian refuses to officially support, eg editor and jql-editor libraries. They have a “high” vulnerability in the dependency tree for over a year now, due to outdated styled-components library dependency.

UPD: moreover, this raises the question whether Atlassian is willing to adhere to the same rules. Because these libraries are widely used in the products (Jira and Confluence for sure)

10 Likes
10

Hi @clouless, thank you! It depends on what the “custom permissions” are trying to achieve really. We do not recommend attempting to build an “offline copy” of the product permission model in your app, as it would quickly become out of date from the permissions enforced in the products. However, If all user permissions are explicitly checked (mind you to be conscious about the possible permissions changes on the product) when using asApp() to restrict any elevated access, it will be inline with the intent of the requirement. Happy to assist you and discuss more of your use case - you can raise a ticket here.

1 Like
11

Hi @marc, both Connect & Forge apps are prohibited from requesting Atlassian API tokens from users and are not allowed to store them or use them in any way per the updated security requirements for Marketplace cloud apps. Apps should only authenticate with Atlassian products by using approved authentication methods such as JWT authentication (for Connect) or Product Fetch API (for Forge).

When apps utilize authentication methods like Atlassian API tokens and user credentials, it undermines several of the trust and security controls that we have in place to protect customers and partners. For instance, if a Marketplace app is compromised and an attacker obtains access to an Atlassian API token belonging to a user that is being stored by that app, it is extremely difficult for Atlassian to identify that the attacker’s REST API activity is originating from a specific app instead of from a specific customer. If the app was using an approved authentication method instead, Atlassian could identify the anomalous activity and take action to notify both the affected customer and the partner about the possible compromise possibly reducing the impact significantly.

Some partners have already indicated that they require Atlassian API tokens to access specific product REST APIs that do not currently support app authentication. Apps that are currently utilizing Atlassian API tokens for this purpose who report the situation to Atlassian will be granted a waiver on this specific requirement while we escalate with the appropriate engineering teams to add support for app authentication to these APIs. We are happy to assist you and discuss more of your use case, you can raise a ticket here.

12

Hi @danielwester,

This would let us explain to customer why other application types (such as standalone apps using oAuth).

Sure, we will link supporting documentation on the DAC page.

Just a bit nitpick here - but why is #10 (" An application must not collect or store credentials belonging to Atlassian user accounts such as user passwords or user API tokens.") under Privacy? Especially since the linked document doesn’t talk about user credentials.

It was added under Privacy due to its impact on unintended access to cross-product (Jira/Confluence/JSM) data. Atlassian API keys are not scoped and allow similar access to product REST APIs that user credentials provide. The link was provided as a reference to general privacy guidelines.

For the Forge scopes - I’m a bit confused. The granular scopes is on hold according to Action required: Update scopes for Forge and OAuth 2.0 (3LO) apps - should those sections be removed?

I understand and apologize for the confusion on this topic in general. Our intent for this requirement is to make sure apps are not asking more than what they need, regardless of what’s made available to them by Atlassian. So when an app just needs read access, it must not ask for write access. Though Forge granular scopes are paused for now, the original intent remains the same i.e. do not ask for scopes that are not needed for its functionality. The timing here is really unfortunate with granular scopes being paused and the security requirements talking about the scope - but the objective holistically is about requesting only required scopes.

Hi @kazimir_io ,

This once more time brings up the question what should we do about Atlaskit libraries that are essential to the apps and are too complex to DIY for vendors, but Atlassian refuses to officially support, eg editor and jql-editor libraries. They have a “high” vulnerability in the dependency tree for over a year now, due to outdated styled-components library dependency.

NPM packages published under the Atlaskit scope are officially maintained and supported by Atlassian. We scan Atlaskit packages (and other Atlassian Frontend packages published to NPM under Atlaskit scope) for vulnerable versions of 3rd party libraries and dependencies on daily basis. We track these vulnerabilities and address them as per our internal priority scores. We are interested in knowing the unpatched “high” severity vulnerability you mentioned and we are happy to address it if you can raise a support ticket with us and provide more details on your finding.

13

Well the issue is that when we tell customers that we follow Atlassian security guidelines - they go “awesome” and then dig into it during their procurement process. When the guidelines then conflict with reality (as in this case) - we then end up having to tell the customers that Atlassian doesn’t really know what’s going on with their own programs


Ideally you would leave this off until the rest of Atlassian can support your effort and then add it in.

14

Ohh ohh - I know this one. styled-components. Atlassian editor (for example) requires styled-components from X years ago - there is no eta on when it will be fixed.

We can also just go along with anything that reads adf and how it’s not compatible with new versions of react (which is just a matter of time before it becomes a problem).

1 Like
15

That sounds like an Atlassian issue - why aren’t Atlassian API keys scoped properly? When will Atlassian security require them to be scoped properly? (I would love for this to happen so that I don’t have to worry about Forge using them).

3 Likes
16

@SrivathsavGandrathi
While not strictly a dependency, atlassian-connect-express-template is full of security issues. This is the starter template for the ACE tutorials.

1 Like
17

Can you please design an approved way to render ADF content? Your rule against unsafe-inline CSPs prevents us from rendering ADF content.

  • We need to display excerpts of a Confluence page,
  • For example, we need to display a preview of the Confluence page, where we highlight the part (table cell, headers, images
) which we will change, so we need to interact with the rendering.
  • Another example is that we extract “requirements” from Confluence tables and display them in all sorts of places, so we need a safe way to render them,
  • It means we render ADF in a <div>, and apply the styles for the macros, and therefore we need to use inline styles. Maybe you’ll make an <adf content={adf} in-the-context-of={pageId} /> React component :wink: ? (But we group all ADF and perform a render request to Atlassian once for the whole page).

If Atlassian designs a safe way to do this, for example with a predefined CSS that covers all the built-in static macros, we’d be happy to use it.

2 Likes
18

We also use API tokens for user access of rest services not available in connect. It’s got super old years ago trying to raise these API deficiencies with Atlassian. If this is a to actually get your API’s usable so that such tokens are not required, that’s fantastic. Less fantastic is if we have to repeatedly justify the same workarounds to ‘new’ staff every time the ‘temporary’ approval lapses. Can you retain the explanations to limit repeat effort? Even better, can ‘temporary’ mean permanent until Atlassian actually address the root cause of lacking API’s 
 Otherwise its just tedious make-work


19

Question on connect authentication:
Currently you can build and distribute an app with no authentication, i.e. a completely static app. This is described in https://developer.atlassian.com/cloud/confluence/connect-app-descriptor/ with authentication: {type: none}.
The new security requirements seem to imply that you must use authentication: {type: jwt} and validate the install lifecycle request.
This in turn would mean that purely static connect apps are not allowed anymore.
What is the Atlassian position on this?

2 Likes
20

@danielwester We will remove references to granular scopes for now but the overall intent of apps requesting minimal available scopes remains the same. FYI, we are in initial stages of addressing Atlassian account API token management.

@marc Thank you for informing, please note that configuration in templates may refer to development environment. We are happy to look into if you can share high impact issues noticed in atlassian-connect-express-template via a support ticket.
we are also aware of authentication: {type: none} use case and added a waiver for anonymous access in the Authentication & Authorization requirement. In order to avoid further confusion, we will also include below waiver to Connect specific section.

Only set authentication type to None in the app descriptor if all of the endpoints in descriptor serve only static content or do not include dynamic application data in their response.

@aragot For this specific feedback we are happy to connect you to right team and see if there are alternatives if you can raise a support ticket with us.

@AndyD Understood, we will document this waiver so that you do not have to explain until the waiver is addressed.

1 Like