It is important to note that this dependency has been deprecated for more than 3 years. A pull request exists from a community’s volunteer to bring attention to it as the description indicates to treat it more as a Jira Issue than an actual PR with the definite solution.
ACE is greatly embedded in our plugins so it is of utmost importance that this vulnerability is fixed.
Can we please get a response from Atlassian? I don’t get why security questions are ignored here in this forum. Are we supposed to open support requests?
Does the vulnerability in request have any security impact on apps using atlassian-connect-express? As far as I understand, request is used to make requests against Confluence/Jira and against the Atlassian Authorization Server. I don’t see how SSRF would be possible there. And is anyone even using a custom agent for this?
Hi @Archer and others, thanks for bringing this to our attention and for your interest, and please accept our apologies for the slow reply.
First of all, we’ve looked into this and it seems that apps that could be affected are those that use request to make GET requests to user-provided URLs, with the default request behaviour of following redirects (and those who make other kinds of requests who have explicitly configured requests to follow these). If this isn’t your app, there’s likely no risk to your app.
This should be enough to keep atlassian-connect-express apps secure from this particular vulnerability, but we’re happy to hear your concerns or feedback if you think more needs to be done to address the immediate risk.
Secondly, there is the broader question of what is to be done about atlassian-connect-express having a dependency on the no-longer-maintained (as of 2020) request library. We’d especially like your thoughts on this one. I’ve already put my thoughts on the pull request linked above but haven’t received any input there.
In short: dropping request would be a big breaking change because the HTTP client API exposed by atlassian-connect-express is inextricably coupled to the request API. It is not feasible for us to write our own adapter compatible with the request API surface, so what we’d likely do instead is provide library-agnostic methods for generating request particulars such as authentication headers, for app implementers to make use of along with their http client of choice. I’m loathe to just wrap a different library such as axios, for fear that we end up in the same situation a couple of years hence.
Would you be willing to make the necessary adaptations to this breakage in order to shed the request dependency?
Thanks again,
James Hazelwood
Principal Developer
Atlassian Ecosystem Platform
PS: If there are no objections, I’ll look into integrating the redirect blocking workaround into the default configuration of the api-supplied client in the forthcoming major ACE version for the benefit of app developers who don’t catch word of the workaround.
@jhazelwood Have you thought of using fetch (or node-fetch) as a a library? All the Atlassian API documentation already uses it, and this seems to be the new “standard”.
And indeed I would recommend against using something like axios, which will be outdated in some time also.
Hi @marc, you make a fair point: given that fetch is part of the browser API, node-fetch probably is a safer bet than something like axios. I’ll consider this with the team. Are you saying you’d be prepared to rewrite your code from request to fetch, then?
Hi @jhazelwood ,
Sure, I would be happy to rewrite, given an extended deprecation period.
I believe our code only uses request through httpClient and Atlassian libs.
However that might be different for other vendors.
Probably longer term fetch is the best bet for stability.
Hi @jhazelwood ,
because so many vendors (and maybe even internal developers) have built apps on ACE, I believe the only viable solution would be to “fork” ACE before replacing request, and then maintain both versions for at least 2 years. Which, with a fork, should be fairly painless.
