Security concerns on Confluence Cloud

Confluence Development Confluence Cloud
,
1

Hello,

Currently I’m developing a Confluence Plugin for Cloud enviornments, and I’m worried about data security. By creating this plugin, I doubt about any other Confluence plugin security.

I know there is a security program, but it relates to stored data, not network traveling data. Indeed, Confluence api encourages to send data in a non-secure way.

The problem here is that I want to notify about the problem I see, but I’m not sure about where to apply. I will explain it.

All communications with Confluence are done by HTTPS. That’s fine. But HTTPS doesn’t encrypt the URL itself. According to documentation, a Confluence Dynamic Content Macro cannot use POST protocol, so any Dynamic Macro with {macro.body} parameter will send data in the url, that is, in clear text.

Following the thread, Static Content Macros may use the renderingMethod GET so, they could have the same problem.

Indeed, in these two scenarios, it is possible to avoid the {macro.body} parameter and request the body to the server always, but this is going to be slower than using it (until macro.truncated=True). So, secure plugins will be slower than unsecure ones.

Finally, once the Editor is loaded, Plugin developers are running any JavaScript code they want, so potentially they could send a request over GET or an AJAX request over HTTP sending data in an insecure way.

I must say I already found at least two of these problems in the only plugin I’ve being looking.

So…
How much should I trust on the Atlassian Security program?
Do yo know if there will be future improvements in order to certify communications too?
How can my plugin (using GET minimal data and then POST and cyphered data for any server connection) show that it is more secure than others?
How should I send these concerns to Atlassian?

2

You’re assumption that URL is not part of the encrypted HTTPS connection is incorrect, see also ssl - Are HTTPS URLs encrypted? - Stack Overflow

2 Likes
3

Holly shit.

You are completelly right. I didn’t thought it was going to be translated to the IP by OSI levels. I doublecheked by using tcpdump and, as you said, it was cyphered.

Anyways, that justifies two of the three points I shared. What about the Javascript requesting by HTTP or other stuff?

In addition… Now I feel like a fool some how XD

4

Haha, no worries. You’re not a fool, or if you are, you are in good company as I think 99,99999991% of the world doesn’t know this. It is a common misconception, and TCP/HTTP layers often get confused.

Regarding the Javascript… Atlassian Connect (AC) add-ons run in iframes and are served from the vendor service provider. So to some extend, security wise, the code is executed in a contained environment within the page. However, AC does provide API endpoints that allow vendors to retrieve data from the AC host application and potentially, vendors could indeed (by accident) forget to use https to sent the data to their server, or even worse share this data with 3rd parties.

I guess Atlassian somewhat tried to limit this problem by enforcing add-on content to be served from HTTPS. In most cases, vendors will use relative URLs in their code base. If they do, the content will be sent over HTTPS. The vendor will actively need to specify an HTTP endpoint in their javascript XHR request. And that would be just malicious. If you encounter this, you should report the add-on to Atlassian.

2 Likes