Fondamenti di Sicurezza Web: SSRF, CSRF e CORS Spiegati

Nel panorama web moderno, la sicurezza non è solo una funzionalità, è una base fondamentale. Man mano che le applicazioni diventano più interconnesse, comprendere le sfumature di come vengono gestite le richieste tra diverse origini e server è cruciale per ogni sviluppatore.

Oggi approfondiremo tre concetti critici che ogni sviluppatore web dovrebbe padroneggiare: SSRF, CSRF e CORS. Anche se possono sembrare una zuppa di acronimi, rappresentano le linee del fronte della sicurezza delle applicazioni web.

1. SSRF (Server-Side Request Forgery)

SSRF è una vulnerabilità in cui un utente malintenzionato può costringere un’applicazione lato server a effettuare richieste HTTP verso un dominio arbitrario scelto dall’attaccante.

Come Funziona

Immaginate un’applicazione web che accetta un URL come input (ad esempio, per recuperare un’immagine del profilo o visualizzare l’anteprima di un link) e poi effettua una richiesta a quell’URL dal server. Se l’applicazione non convalida correttamente questo URL, un attaccante potrebbe fornire un indirizzo IP interno o un indirizzo di loopback (127.0.0.1).

Il server, agendo come proxy, potrebbe quindi recuperare dati sensibili da servizi interni che non sono esposti al pubblico internet, come:

• Metadati Cloud: Accesso a 169.254.169.254 su AWS/GCP per recuperare le credenziali IAM.
• Pannelli di Amministrazione Interni: Accesso a strumenti interni come Jenkins o dashboard Kubernetes.
• Scansione delle Porte: Scoperta di altri servizi in esecuzione sulla rete interna.

Prevenzione

• Allowlisting: Consenti solo richieste verso un elenco predefinito di domini attendibili.
• Convalida dell’Input: Assicurati che l’URL utilizzi protocolli consentiti (es. solo https://) e non punti a intervalli di IP interni.
• Segregazione della Rete: Assicurati che il server web abbia un accesso limitato alle risorse interne.

2. CSRF (Cross-Site Request Forgery)

CSRF è un attacco che inganna il browser della vittima facendogli eseguire un’azione indesiderata su un altro sito web in cui la vittima è attualmente autenticata.

Come Funziona

Questo attacco sfrutta il fatto che i browser includono automaticamente le credenziali ambientali — come i cookie di sessione — con ogni richiesta a un dominio.

1. Un utente accede a bank.com.
2. L’utente visita un sito dannoso evil.com in un’altra scheda.
3. evil.com contiene un modulo nascosto che invia una richiesta POST a bank.com/transfer?amount=1000&to=attacker.
4. Il browser invia la richiesta insieme al cookie di sessione dell’utente per bank.com.
5. bank.com vede una sessione valida e processa il trasferimento.

Prevenzione

• Token Anti-CSRF: Includi un token unico, segreto e imprevedibile in ogni richiesta che modifica lo stato. Il server verifica questo token prima dell’elaborazione.
• Cookie SameSite: Imposta l’attributo SameSite sui cookie a Strict o Lax per impedire che vengano inviati in richieste tra siti diversi.
• Header Personalizzati: Per le richieste AJAX, richiedi un header personalizzato (es. X-Requested-With) che non può essere impostato da un modulo HTML standard.

3. CORS (Cross-Origin Resource Sharing)

A differenza di SSRF e CSRF, il CORS non è una vulnerabilità in sé, ma un meccanismo di sicurezza. È un modo per i server di dire al browser: “Va bene che questa specifica origine esterna acceda alle mie risorse.”

Perché Esiste

Per impostazione predefinita, i browser applicano la Same-Origin Policy (SOP), che impedisce a uno script su un sito di leggere dati da un altro sito. Questo impedisce a evil.com di leggere le tue email su gmail.com.

Il CORS consente ai server di allentare questa politica in modo sicuro. Quando un’app web effettua una richiesta cross-origin, il browser invia un header Origin. Il server risponde con Access-Control-Allow-Origin.

Configurazioni Errate Comuni

• Origine Wildcard (*): Consentire tutte le origini. Sebbene vada bene per le API pubbliche, è pericoloso se combinato con Access-Control-Allow-Credentials: true.
• Riflessione dell’Origine: Impostare dinamicamente l’origine consentita in base all’header Origin senza convalida. Questo bypassa efficacemente la SOP del tutto.

Best Practices

• Sii Specifico: Consenti solo i domini specifici che necessitano di accesso.
• Evita le Credenziali se possibile: Se la tua API non necessita di cookie o header Authorization, non consentirli.
• Usa un Middleware di Sicurezza: Usa librerie ben testate per gestire la configurazione CORS invece di gestire gli header manualmente.

Confronto Riassuntivo

Comprendere questi tre pilastri della sicurezza web è essenziale per costruire applicazioni moderne e robuste. Implementando strategie di difesa in profondità, puoi proteggere sia l’infrastruttura interna del tuo server che i dati privati dei tuoi utenti.

Rimanete al sicuro e buon coding!