Atlassian has made a security change to the Confluence Content Body Conversion API. When this API is called by an app, any macros in the content, which are provided by another app, will not include that app’s context JWT. This means the macro may not be rendered by calling that app’s endpoint.
We do not expect apps to be rendering macro content from other apps so we do not expect this will impact most apps. If your app is impacted, please contact us to let us know why your app needs to perform this operation.
@cmacneill Can you please clarify where exactly the JWT will be omitted?
Our apps retrieve storage format from Confluence, adapt it, then send it back to the conversion endpoint in order to transform storage to export_view format. During this conversion Confluence potentially invokes third party macro endpoints. Are you saying that Confluence will no longer include the JWTs for the macros in these invocations?
This would completely breaks our app’s integration with other third party macros!
We need to be able to manipulate macro definitions when modifying the storage format (e.g. macro parameters) in order to optimize the macro output for exports and to add context information.
I guess that’s the beauty of a vibrant ecosystem: that these crazy vendors find ways to use the product and API’s in ways you did not expect.
What puzzles me a bit is that we had a call just last week explaining how these type of changes require prior notification and that it’s probably not wise to do so in vacation period.
Can you elaborate on the reason for expediting this change, maybe share the risk matrix score? That way we can get a better understanding on why this is happening now
@cmacneill After thinking a bit about this I wanted to add the following:
I know that the conversion endpoint can output iframe elements for dynamic content macros if they don’t have a static mode. I believe in this case the JWT was also present in the iframe tag’s source.
Removing this JWT probably makes sense and it would not affect our apps because we require other macros to implement a static mode.
I got another question: Has the announced change been rolled out to all instances yet?
Second Jen’s concern. Can you elaborate? When content is rendered is it resolved real-time or would the JWT would be required for that third party to rendered?
Rendering of content as-seen-by-the-user is fundamental for content management apps (K15t’s, Comalatech’s), so @cmacneill, the impact is bigger that you’d imagine.
We are indeed endeavouring to give ecosystem vendors advance notice of changes. Unfortunately security fixes must be handled differently at times.
Where we believe disclosure of a vulnerability prior to fixing that vulnerability would present an unacceptable risk of exploitation we are obliged to fix the issue prior to disclosure.
I fully understand and appreciate this! But it would really help, in these cases, if you share more of the rationale as to why you consider this a fix that requires immediate remediation.
To me, it feels like a fix like this could have easily waited until September. So the question is: what happened? Was it discovered as part of the bug bounty program and did you just put the remediation SLA on it? Did you discover it yourself and considered this an urgent fix because of a risk score calculation?
Giving more contextual information about these fixes would help us understand and appreciate them better.
Thanks sounds good, so just to clarify this once and for all:
Am I right to assume that Confluence still JWT-authenticates requests to static third party macros when we use /wiki/rest/api/contentbody/convert/export_view with storage input containing such macro definitions?
Sorry for being persistent here, but this is a critical aspect to our apps and there are just too many black boxes involved to analyze this efficiently myself.
Our apps retrieve storage format from Confluence, potentially adapt it, then send it back to the conversion endpoint in order to transform storage to view format.
This is to display in our iframes the content of the macros. In one case we simply display the content in multiple tabs (Navitabs), the other use case we have
is to display macros depending on the user language (Translations for Confluence). Users expect there to insert whatever content the editor allows them to and to see it afterwards displayed.
So is this use case now dead or should we tell the customers “you can’t use 3rd party macros anymore?”
I’m a bit surprised that such a critical change with such an impact is rolled out without any alternative.
@remie giving a risk rating is hard for an issue like this, because it’s dependent on how apps were using this particular issue.
From our side we investigated apps that may be impacted, and that number was very low. Based on the risk vs the impact it was decided that we move forward and resolve this issue on balance of risk, knowing that a small numbers of apps may be impacted by this change.
For any vendor experiencing issues with their apps and believe that this change is the root cause of their issue, they can raise a DEVHELP ticket here and we will be able to investigate a solution to the issue with you.
With your change yesterday, however, you seem to have created new problems.
For example, on pages migrated from the server that still use the legacy editor, our tab macros are no longer rendered as soon as there is a table of contents or code block on the page (not nested within our macros). https://jira.atlassian.com/browse/CONFCLOUD-72485
Is this a change you want to make for security reasons or just a bug in the implementation?
Certainly appreciate security issues have to be fixed.
What puzzles me a bit is why your team wouldn’t scan logs or if there are GDPR concerns then to set up a scanner to record when macros are rendering other macros? Even if you had to make the security fix first the answer to this expectations is within Atlassian’s Confluence Cloud system.
The Confluence Server/DC team would frequently examine vendor apps for compatibility with new versions of Confluence and alert individual vendors weeks or longer ahead of new version deployments. Again if you had to implement a critical security fix sooner that’s understandable, but the level of service to Confluence Server/DC differs quite a bit and I’m not clear why that is?