Action required: Atlassian Connect vulnerability allows bypass of app qsh verification via context JWTs

Announcements
, , , ,
41

All AMS vulnerability tickets for Bitbucket Cloud apps have now been closed as False Positive.

1 Like
42

Hi there,

@HeyJoe I haven’t quite understood what we should do.

We have an Atlassian add-on, inside which we use jwt authorization for our API.
I already understood that we should do change the descriptor and that that object.
But the second part isn’t clear to me. Should we change the authorization part of the lifecycle events in our API? Or there is something that we should also do in our frontend part which uses jwt to connect API?

Thanks

1 Like
43

Maybe this helps: Action required: Atlassian Connect vulnerability allows bypass of app qsh verification via context JWTs - #4 by remie

1 Like
44

Sorry @remie, I’m a little confused.

Is it so that we should use this library to do the authentication part?

As I understood for all requests we should add a middleware, just depending on if it’s lifecycle hook add a flag. But why the library requires storage?

And what if we just skip this process in our backend, because we already have some authentication processes which verify the lifecycle requests come from AC? Will it stop working?

45

Hi,

Endpoints that serve iframe content - do we need to validate qsh for all endpoint mention in descriptor file?
Because my app resource hosted inside AWS s3 static hosting ( frontend - ReactJS )

"webPanels": [
      {
        "key": "<key>",
        "location": "atl.jira.view.issue.left.context",
        "url": "/DemoUI/#/storyview/{issue.id}?projectId={project.id}",
        "weight": 300,
        "name": {
          "value": "name"
        }
}
]

Does this mean we have to move our static hosting under web server to validate before we serve our static content?

Thanks,
Umang

46

@umang.savaliya - how are you validating the JWT for iframe requests currently?

Perhaps you could consider moving the static content behind CloudFront, and then use Lambda@EDGE to validate the token? That way you wouldn’t need to move away from a static hosting model for your frontend resrouces.

1 Like
47

@HeyJoe - Currently all my static resource behind CloudFont only.

we are planning to move all our static resource under s3 to get some more benefit of static hosting capability. I asked this question in advance, do we need to validate jwt in this case too or not if we take s3 approach.
Also, Thank for explanation. I got idea what change need to do if we move our resource to s3 bucket.

Cheers,
Umang

1 Like
48

We have similar use case. We serve only static react apps on ui endpoints declared in Atlassian connect descriptor. We don’t need to validate JWT because for each endpoint we always serve the same static content as we don’t differentiate on the server level the content by tenant or the user.

Why should we even care for JWT validation in this case? I understand that when having some templating on the server level to inject things dependent on the user and tenant to the content requires to validate JWT but for solely static content there is a little overhead without any security level improvement.

Or am I missing a point?

3 Likes
49

Hello all,

We have Atlassian Connect application which receives WebHooks from Jira Cloud (on create, update and delete events). Is qsh verification change related to WebHooks? Will there be claims added to WebHook JSON infos?

Best Regards,
Ivan Babikov

1 Like
50

Hi All,
I am using “authentication”:{“type”:“jwt”} in my Descriptor.
and have made the changes in My descriptor and added:
“apiMigrations”: {
“context-qsh”: true
}
Now what are the other changes that need to be done?
Please let me know.

Thanks

1 Like
51

Hey @HeyJoe,

As part of solution, we are taking care of below points.

  1. Opt into the context JWT qsh claim behaviour by updating apiMigrations Connect app descriptor
  2. Update app endpoints that need to accept context JWTs to allow static qsh claims
  3. Ensure you’re not accepting context JWTs in app module (web panels, lifecycle hooks, etc) endpoints

However we have below questions for IFrame JWT,

Do we require to validate (i.e. regenerate and compare) QSH claim in JWT for web panels, generalPages from backend? If we will not do this before 7th June, does our app breaks?

Awaiting for your answer.

Thanks,
Umang

1 Like
52

@umang.savaliya If your module URLs point to public/unauthenticated S3 URLs then there’s no way to validate the JWT (to verify only Atlassian can request your app). The iframe JWT can’t be validated on the client side.

That being said, it sound like you’re implementing https://developer.atlassian.com/cloud/confluence/cacheable-app-iframes-for-connect-apps/ If you mark the module as cacheable: true then there won’t be a JWT sent to your S3 URLs. You’ll still need to validate the app context JWT on requests from your app frontend to your app server.

Do we require to validate (i.e. regenerate and compare) QSH claim in JWT for web panels, generalPages from backend? If we will not do this before 7th June, does our app breaks?

Yes, the qsh should be validated in this case if your iframe module is served from your backend server (and not serving a simple static file from something like S3).

1 Like
53

Hi @ivan.babikov,

There hasn’t been any changes to webhooks implemented as a result. Webhooks sent from Atlassian to your app include a JWT with a qsh value calculated against the webhook endpoint to which they were sent. You can validate the qsh claim per https://developer.atlassian.com/cloud/jira/platform/understanding-jwt-for-connect-apps/#a-name-qsh-a-creating-a-query-string-hash

Regards,
Zac

54

Thank you so much for this summary @remie. The original post here is really misleading, when it says that the context JWT is only used for the “cachable app iframes”. Not true. In fact, as you say, any calls from the frontend of a connect-iframe to the backend must be annotated with @ContextJwt otherwise you get 401 not authorized.

55

Hey guys,
I’ve created a PR (upgrade to v.2.1.5 for atlassian-connect-spring-boot-sample-dynamodb): https://bitbucket.org/atlassian/atlassian-connect-spring-boot-samples/pull-requests/8/atlassian-connect-spring-boot-sample
Let’s review!

56

@zsims

we are not getting JWT with qsh on below confluence cloud descriptor (renderModes → pdf/word/default). is this intended behaviour ?

"dynamicContentMacros": [
      {
       ...,
        "renderModes": {
          "pdf": {
            "url": "/<appselector>/rest/getpdf"
          }
        }
      }
    ]

Thanks,
Umang

57

We have our custom implementation to check JWTs and we are facing some issues while checking Jira context JWT qsh for some customers.

The problem is that AP.context.getToken() is generating JWT without qsh for some customers so our rest api endpoints are responding with 401. We have to revert our qsh verification to unblock a few customers.

From what i understood we must verify qsh for Jira context JWT as well. What’s going on?

58

The value of the QSH claim of a context JWT will always be context-qsh. So if you want to validate the QSH, you should not be validating against an actual calculated QSH, but just this plain text value.

59

Thanks for quick answer @remie.

We are validating QSH of context JWT with fixed context-qsh plain text, indeed. We are following exactly the pseudo algorithm you pasted in a comment. The descriptor is also ok and it was deployed to production a few weeks ago.

The point is that, for a few customers, AP.context.getToken() is generating a JWT without qsh claim. We had to remove the qsh validation (for endpoints that verify jira context jwt only) in order to unblock those customers.

Is it expected that in some scenario AP.context.getToken() generates a JWT without qsh claim?

60

@HeyJoe I have a front-end code only app where authentication is JWT and scopes read, which is required because /search/user won’t work otherwise. Should I still set apiMigrations? BTW it was flagged as a false positive in the ecosystem AMS ticket.