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.
If this is you, there seems to be a fairly low-risk and straightforward workaround - see this branch off the standard ACE template for details.
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