RFC-116: New link egress type for Forge apps

General Request for Comments (RFC)
,
22

This is not my company’s stance, just personal thoughts on this matter.

I think Atlassian is overcomplicating their approach to RoA and data isolation.
A fully RoA compliant Jira app can currently send and receive arbitrary data from the outside world: I won’t write the details here since this is a public forum, but it’s possible and it can be done by simply using a few Jira APIs, we can discuss it separately if you want.

I understand that a sneaky app developer might use links to send data via query or path params, but this is really a byzantine solution to the problem: the risk of configuration drift between the manifest and the actual links in the app is very high, the manifest will get polluted with a huge wall of text.

Please, reconsider what Runs on Atlassian means: either it means that all the code is running on Atlassian infra, in which case the name is reasonable and it makes sense, or it means “no data can leave Atlassian”, in which case not even Jira would comply with the definition, considering that project admins can configure automations that create Google Drive documents, send emails or web requests to arbitrary URLs…

8 Likes
23

Yes, a malicious app can leak data out of a runs on Atlassian compliant app. I have a few ways in my mind. However, I don’t think having effort to have a ‘fully-malicious’ app resistant sandbox for Runs on Atlassian would be worth the time. So, yes: It is frustrating to have all these hoops for something basic like links.

Back on topic: It would work for like one of our apps. The vast majority of our apps cannot be Runs on Atlassian. We in general are more waiting for RFC-94.

Question: If a link points to a location that is allowed by Configured Egress, would the the warning also disappear?

2 Likes
24

Hi @VickyHu -

I’d like some clarification about whether listed statics links that result in a redirect would be compliant or not. The original post mentions risks introduced by, among other things, redirects. Several comments seem to assume that redirects will be part of their solution. Your latest summary doesn’t address the topic. I’m unclear what Atlassian expects here. It does seem, though, that urls that redirect (via a URL shortener, for example) could be construed to violate the transparency this proposal intends to deliver.

1 Like
25

Hi @VickyHu ,

One aspect of urls I’m missing in this discussion is the use of the hash identifier: URL: hash property - Web APIs | MDN . I hope Atlassian will allow the use of a variable hash identifier, as this hash is used to send the browser to the matching id in a html page. We use this in documentation pages to send the user to e.g. the configuration section or the usage section.

So my ask is: Allow to define a single url, and allow this single url to have a variable hash identifier.

3 Likes
26

@marc – Is that the same as an HTML anchor? If so, the RFC specifies that variable anchors would not be supported. (Unfortunately)

27

@AaronMorris1 , Thanks for the info. Unfortunately it seems the variable URL hash property will not be supported.

@VickyHu : Our apps can put variable URLs into the page content and into comments. However we can’t put the same “dynamic” URLs into our addon. This really seems like a strange limitation. However I can understand to force opening an external URL in a new tab of window. By that it is abundantly clear to a user that they are outside of Atlassian.

28

Thanks for explaining this goal, since it helps us better understand the risks that Atlassian is trying to cover.

What about a compromise, where Atlassian allows vendors to (say) allow one single templated query parameter (or URL fragment), and force it to be an integer in the range 0-65535? eg. https://mysite.com/kb?id={ID}

This would allow most vendors to build redirects on their side to handle as many pages as would be reasonably required for most apps.

In terms of the “no egress” goal, yes, this could theoretically allow a malicious actor to egress up to 16 bits of data per link clicked. But the user also actually has to click on the link.

Furthermore, even in the case where we go with Atlassian’s strict definition and there is a statically-defined list of links, I can still egress data. For example, if I declare link0…link255 in my manifest, my app gets to decide which of those 256 links it presents to the user. That choice egresses 8 bits of information. With the idea above, we are talking about the egress of 8 additional bits.

I ask Atlassian: is having a tolerance of absolute zero actually required here, and if so, does that benefit outweigh the significant management constraints it imposes on vendors?

For example, RoA apps can already silently egress data (with no user action required) one bit at a time through the response codes of a RoA web trigger, and this is far easier to sneak in than by encouraging admins to click on KB links.

If there is a concern about link clicking, malicious apps can also silently read and modify URLs in existing host product pages/issues and force them to link to arbitrary sites with arbitrary query parameter data (while modifying the display URL to be something that looks clean).

The point is that the platform is already imperfect, so maybe there is a way to have some flexibility here for vendors without significantly impacting the security posture of the platform.

10 Likes
29

Hi @VickyHu – Given the key risk you described, would it be agreeable for Atlassian to automatically whitelist (or pre-authorize) certain domains that it knows to be safe? For example, atlassian.net, youtube.com, github.com, etc., are common domains that many vendors link to for various reasons. Would preauthorizing known domains like these present a realistic risk of data egress?

If not, this would reduce complexity for a not insignificant number of vendors.

2 Likes
30

Hi @VickyHu ,

After thinking about the new link egress RFC, I think it should be merged with RFC-94: Configurable Egress and Remotes . It seems Atlassian is concerned with data egress through links, and data egress is handled in RFC-94.

With two conceptually overlapping egress definitions, the manifest gets complex fast, and complexity is antithetical to security. I also doubt is understandable for developers, let alone customers.

1 Like