Requests are made to the user-provided URL by CloudTube. This means that services running on the same intranet which are not exposed to the public internet, may be able to have data leaked by setting an IP as the instance field so CloudTube connects to and returns data from it.
This can be prevented by restricting the possible values that can be entered in that field. The instance owner should have some amount of control over how this is done.
List of IPs that can't be connected to in CIDR format. Disallowing 127., 10., 192.168.*, and so on, would solve this issue.
Potential issue: CIDR format is complex and easy to get wrong.
Only connect to a pre-approved list of domains.
Issue: People wouldn't be able to use their own private Invidious instances any more, unless they were on the list, but then they'd be public.
Potential issue: Bad actor sets up an Invidious instance, puts it on the public list, gets it into CloudTube, updates the DNS to 127.0.0.1 (or another internal IP) and then is able to issue requests to the intranet, for a short period of time until the domain is banned.
Discuss!
Here is a list of private ranges in CIDR notation from another project with similar security concerns: https://github.com/matrix-org/synapse/blob/e12077a78afb8f0e7931a0930aebe5081023d5f9/docs/sample_config.yaml#L169-L187
I think solution 1 is preferable, but it would benefit from having an extra list of 'exceptions' to the block list, e.g. block '127.0.0.0/8' but permit the single service '127.0.0.1:7331'.
Ugh, right. We'd also have to allow/deny by port, since some services (NewLeaf!) should be accessible, and others shouldn't be, on the same server.
That's so annoying, but I guess we'll have to live with it...
What about both solutions at the same time?
Have a configurable list of disallowed CIDRs and a configurable whitelist of instances (extended from the public ones retrieved in #13)?