Securely embedding all.js third-party javascript

#1

In order to build an Atlassian Connect app, I need to embed a third-party JavaScript file in the pages rendered by my app (all.js).

Embedding third-party JavaScript is known to be risky business, I need to trust the vendor to not include any malicious code that’s trying to grab information from my app it’s not supposed to access.

OWASP acknowledged this as a major risk and they recommend counter-measures to avoid some of the common risks.

As far as I see, I don’t have a lot of options to securely embed Atlassian’s JavaScript. Subresource Integrity checks don’t seem to be available and the custom cross-domain JavaScript bridging handshake that happens before embedding my content in an iframe make it impossible to further isolate all.js in another iframe sandbox.

Any ideas how I can be on the safe site when including all.js in any of my pages without risking leaking information because of malicious code that could potentially be contained in all.js?

1 Like
#2

I mean… You’re making an Atlassian app but you don’t trust the Atlassian JS library? Seems like you’re one step ahead. :sweat_smile:

#3

It’s the same set of precautions I would take when embedding third-party scripts from social networks (think Facebook’s and Twitter’s social sharing buttons) or ad providers.

The Atlassian app is running in a context that has access to data other than what should be shared with the Atlassian app. I’d love to make sure that the third-party code I embed is not trying to break out of its intended use case. I could do so either by restricting what the code is technically allowed to do or by verifying the code that’s being loaded.

Our industry has seen numerous examples of third-party JavaScript injecting malicious code, trying to steal credit card information, mining cryptocurrency, hijacking sessions, or exfiltrating information. Most of these scripts are included because they originally stem from a vendor deemed trustworthy.

Unfortunately, trusting other parties to play by the rules is not enough to protect your users’ data - if it were, we wouldn’t need same-origin policies, sandboxed iframes or a permissions API.

I acknowledge that there’s a certain amount of trust I have to put into the vendors I choose to integrate with. On top of trust, I’d love to have ways of verifying that I can continue to trust before things turn south.

Things like Subresource Integrity sound like a sensitive measurement Atlassian could offer to avoid distributing unverified code to all the apps out there.

Please don’t get me wrong, I’m not accusing Atlassian of having malicious intent. It only takes an oversight to introduce security vulnerabilities. And if someone should decide to actively introduce shady behavior into a script that’s running in the context of my website, I’d at least be able to verify before that change gets pushed to my site automatically :slight_smile:

2 Likes
#4

I get what you’re saying. You’re likely not going to get features like sub resource integrity because you’re not depending on a version of a library. You’re depending on a “live version” of something that Atlassian wants to be able to change without notifying you… I know, this doesn’t help you with trusting it more. :stuck_out_tongue:

The thing is, though… In this case I’m not really sure Atlassian should be considered a third party. Rather you are the third party and that’s why you are being sandboxed. Not the other way round.

Honestly you seem to have a strong understanding of security and have good intentions. More power to you! But in this case you might just not get your way because of how all of this works. If you find a way of realizing your concept though please share it with the community. I think we would all be very interested.

1 Like
#5

That’s the main issue. I understand why depending on the latest version can be beneficial but it certainly comes with downsides.

I can imagine Atlassian offering a dual approach: distribute all.js as the latest version and have all-{version}.js with a published hash for those who want to upgrade in a controlled and verified way.

It surely is mind-bending to treat the vendor that hosts my third-party app as a third party. However, I think this definition still holds, as I’m required to include someone else’s JavaScript in a site that’s hosted on my domain.

Sandboxing my app’s pages in an iframe (that’s yet another iframe on top of the one that Jira uses to embed my content) has been partially successful. This way, I can control what the embedded page is allowed to do, using the sandbox attribute. However, I need to keep allow-same-origin and allow-scripts enabled in order to make the postMessage communication work that’s happening behind the scenes. Also, two levels of iframes surely doesn’t come without a good portion of headache :slight_smile:

2 Likes