Diventa Autore per CoreTech | Scopri di più
18/11/21 CoreTech Blog
Le vulnerabilità SSRF (Server-side Request Forgery) consentono a un utente malintenzionato di inviare richieste predisposte dal server back-end di un'applicazione Web vulnerabile. I criminali di solito utilizzano attacchi SSRF per colpire i sistemi interni che si trovano dietro i firewall e non sono accessibili dalla rete esterna. Un utente malintenzionato può anche sfruttare SSRF per accedere ai servizi disponibili tramite l'interfaccia di loopback (127.0.0.1) del server sfruttato.
Le vulnerabilità SSRF si verificano quando un utente malintenzionato ha il controllo completo o parziale della richiesta inviata dall'applicazione web. Un esempio comune è quando un utente malintenzionato può controllare l'URL del servizio di terze parti a cui l'applicazione Web effettua una richiesta.
Semplici blacklist ed espressioni regolari applicate all'input dell'utente sono un cattivo approccio per mitigare SSRF. In generale, le liste nere sono uno scarso mezzo di controllo della sicurezza. Gli aggressori troveranno sempre metodi per aggirarli. In questo caso, un utente malintenzionato può utilizzare un reindirizzamento HTTP, un servizio DNS con caratteri jolly come xip.io o anche una codifica IP alternativa .
Il modo più efficace per evitare la falsificazione delle richieste lato server (SSRF) è inserire nella whitelist il nome DNS o l'indirizzo IP a cui l'applicazione deve accedere. Se un approccio alla whitelist non ti soddisfa e devi fare affidamento su una blacklist, è importante convalidare correttamente l'input dell'utente. Ad esempio, non consentire richieste a indirizzi IP privati (non instradabili) (dettagliato in RFC 1918 ).
Tuttavia, nel caso di una lista nera, la corretta mitigazione da adottare varierà da un'applicazione all'altra. In altre parole, non esiste una correzione universale per SSRF perché dipende fortemente dalla funzionalità dell'applicazione e dai requisiti aziendali.
Per evitare che i dati di risposta vengano divulgati all'autore dell'attacco, è necessario assicurarsi che la risposta ricevuta sia quella prevista. In nessun caso il corpo della risposta non elaborato dalla richiesta inviata dal server deve essere consegnato al client.
Se la tua applicazione utilizza solo HTTP o HTTPS per effettuare richieste, consenti solo questi schemi URL. Se disabiliti gli schemi URL inutilizzati, l'autore dell'attacco non sarà in grado di utilizzare l'applicazione Web per effettuare richieste utilizzando schemi potenzialmente pericolosi come file:/// , dict:// , ftp:// e gopher:// .
Per impostazione predefinita, servizi come Memcached, Redis, Elasticsearch e MongoDB non richiedono l'autenticazione. Un utente malintenzionato può utilizzare le vulnerabilità di falsificazione delle richieste lato server per accedere ad alcuni di questi servizi senza alcuna autenticazione. Pertanto, per garantire la sicurezza delle applicazioni web, è meglio abilitare l'autenticazione laddove possibile, anche per i servizi sulla rete locale.
