Description

First thanks to my friend Haxatron for this awsome report

I review the @uppy/companion code from the source to the sink, and I figure out a significant issue that makes any SSRF protection Effectless.

I put myself as a Developer and started to read the companion document, and then I saw Debug option explanation:

debug(optional) - A boolean flag to tell Companion whether to log useful debug information while running.

So we have three options for Debug: 1. true and 2. false and 3. default value that the default value set to true according to this line of code.

Many developers usually don't set optional values, and Also others want to use the debug information.

According to the downloadURL method, the default value of blockLocalIPs is oposite of thereq.companion.options( that has a true value in default and debug mode) .

So we have a false value for blockLocalIPs often, Let's see where the blockLocalIPs will be used :

The blockLocalIPs passed Into getRedirectEvaluator and getProtectedHttpAgent methods

The Mentioned methods are used for validating the URLs and IPs for SSRF issues, and as their second input is false most of the time, Then no SSRF protection will be done.

I also ran for myself companion server with this example code uppy-with-companion, manipulated the inputs to local IP addresses, and made an SSRF attack. (in both dubug=true and false cases )

Impact

A user with URL upload access could enumerate internal companion server networks, send local webservers files to the destination server, and finally download them If each of these files had a guessable and regular name.

Fix suggestion

I think Uppy could use another option ( a new one ) to let users choose whether uploading from the internal network is legal or not, the default value should be false.