@HeyJoe if I update my app descriptor and its URL remains the same, I just have added a new parameter. Should I create a new version of my app in the Marketplace vendor management section? Or new descriptor will be automatically updated by Marketplace?
The Atlassian Marketplace should spot the difference, via polling your descriptor, and make a minor version bump. If that does not happen automatically then you can always perform the change manually.
If I only received webhooks from JIRA after the installation do I only need to add the new field to my descriptor or must I validate the qsh I received in the webhook jwt?
If the requests I make to the JIRA rest API already contain a qsh in the jwt do I need to do anything more?
Hi everyone,
Please note the update to this announcement dated today (May 7 2021) - If your app is using Atlassian Connect Spring Boot, please upgrade to Atlassian Connect Spring Boot 2.1.5 or later, 2.1.4 regressed on the fix introduced in 2.1.3.
Sorry for the confusion!
Hi @MichaelRichardson ,
Because webhook requests to your app are signed with a JWT that includes a qsh claim, you must do both: Add the new field to your descriptor and validate the JWT including the qsh claim in your webhook request handler.
This vulnerability relates to authenticated JWT requests that Atlassian sends to your app, not authenticated JWT requests that your app sends to Atlassian.
@HeyJoe - I just got alerted for this for a bitbucket cloud connect app. I made the fix and added it to the descriptor, and now I’m getting errors per email which looks like the bot is scanning for JIRA or Confluence cloud apps only? According to the documentation (which btw still does not mention apiMigrations), the proper scopes for bitbucket are account or repository.
The .json descriptor provided is invalid (/scopes/0: instance value ("repository") not found in enum
(possible values: ["none","NONE","read","READ","write","WRITE","delete","DELETE","project_admin","PROJECT_ADMIN","space_admin","SPACE_ADMIN","admin","ADMIN","act_as_user","ACT_AS_USER","access_email_addresses","ACCESS_EMAIL_ADDRESSES"])). Check your descriptor and try again.We’ve published a new CVE to cover Atlassian Connect Spring Boot 2.1.4: NVD - CVE-2021-26077
If you’re using Atlassian Connect Spring Boot, please upgrade to 2.1.5 or greater as soon as possible.
1 Like
@jan This issue does not impact Bitbucket cloud connect apps. We rolled out scanning for this vulnerability and mistakenly include bitbucket apps in the scan as well. If you received an AMS ticket for QSH vulns in your bitbucket cloud app, feel free to close those tickets as False Positive. We are also working on auto-closing them.
1 Like
So for now we should not add the apiMigrations to Bitbucket Cloud apps at all? There’s some mixed message on it’s necessity.
The response from the descriptor check is more worrying to me, since that seems to be scanning Bitbucket Cloud descriptors with a Confluence Cloud validation.
Do these changes affect Bamboo plugins?
No, they are only applicable to Cloud apps and there is no Cloud offering voor Bamboo
2 Likes
Thanks
For Jira plugin, we are using this method to verify the JWT: com.atlassian.jwt.core.reader.NimbusJwtReader#readAndVerify in jwt-core-2.0.2. Has it taken care of the qsh validation already? If not, do we have to validate it using the claims? What is the implementation of ComputeQSH
Thanks
The JWT verification does not check the QSH. There is different logic involved, which you can check here: Bitbucket
And do we have to validate it or it is optional? Thanks.
Euhm… well… I mean… it’s your responsibility to create a secure environment. The QSH allows you to validate that the request was not just coming from Atlassian, but that it was also specific for that endpoint.
I guess it depends: if you want to participate in the Cloud Security Program, I think you should validate the QSH where applicable, as I would consider the ability to make a valid request with an invalid QSH a proper security vulnerability when reported in the Bug Bounty program. Which means that you will have to fix it, and pay out the bounty.
If you do not wish to participate in this program, I guess you are allowed to ignore it.
Sorry, I’m confused here; we have a custom implementation of Bitbucket Cloud in which we have the descriptor in a public URL so the app can be installed, and also we get a post-install callback from Bitbucket with the signed jwt (which we validate using the shared secret). Is the change described in this article relevant to Bitbucket?
If I try to add the apiMigrations in the descriptor, we get the error message saying that apiMigrations is not allowed, and using context-qsh in contexts array will cause the installation to fail.
Note: I see that the JWT we get from Bitbucket does contain the qsh claims; besides adding extra validation on the qsh claims, is there something else we need to change? and, do we need to make changes to the descriptor at all?
1 Like
@Luis2 this vulnerability does not affect Bitbucket Cloud apps. If you received a vulnerability notification for your Bitbucket Cloud app, it was raised in error and can be closed as a false positive.
2 Likes
Thank you
Do i need to update atlassian-connect-express (ACE) as well? currently i’m using version 3.0.2.