Sicurezza web: le pratiche che evitano la maggior parte degli incidenti
La maggior parte delle compromissioni di siti web non è mirata. Sono scanner automatici che trovano una vulnerabilità nota in software obsoleto, o una password riusata su un account di amministrazione. Difendersi dagli attacchi ordinari copre la grande maggioranza del rischio reale.
Questa guida copre le pratiche che evitano la maggior parte degli incidenti, grosso modo in ordine di effetto, e cosa fare se un sito è già compromesso.
Le misure che evitano la maggior parte degli incidenti#
In ordine di quanto rischio eliminano per unità di sforzo.
- Tieni il software aggiornato. La stragrande maggioranza delle compromissioni sfrutta una vulnerabilità per cui esiste una correzione. Questo singolo punto pesa più di tutto ciò che segue.
- Password uniche e robuste più autenticazione a due fattori su ogni account di amministrazione, pannello di hosting, registrar di dominio e account e-mail.
- Privilegio minimo. Chi redige non ha bisogno di account amministratore. Rimuovi gli account quando le persone se ne vanno.
- HTTPS ovunque, con HSTS una volta che sei certo che ogni sottorisorsa sia disponibile su TLS.
- Backup collaudati, conservati fuori dal server. Un backup sulla macchina compromessa viene cifrato insieme a tutto il resto.
- Limita l'area di amministrazione per IP dove è praticabile, e limita sempre i tentativi di accesso.
- Rimuovi ciò che non usi. Ogni plugin inattivo, tema e vecchia installazione è superficie d'attacco senza beneficio.
Le vecchie installazioni dimenticate — una copia di preproduzione in /vecchio, un blog di prova in una sottocartella — sono un punto d'ingresso comune proprio perché nessuno le aggiorna.
Input, output e le vulnerabilità classiche#
Sono responsabilità dello sviluppo e spiegano la maggior parte delle vulnerabilità che non siano «non hai aggiornato».
| Vulnerabilità | Cosa fa | Prevenzione |
|---|---|---|
| SQL injection | Legge o distrugge il tuo database | Query parametrizzate, sempre; mai concatenazione di stringhe |
| Cross-site scripting | Esegue script dell'attaccante nella sessione di un visitatore | Fare escaping in output secondo il contesto; una Content-Security-Policy rigorosa |
| Cross-site request forgery | Esegue azioni come utente autenticato | Token per sessione su ogni richiesta che modifica lo stato |
| Abuso del caricamento file | Carica ed esegue codice | Validare il tipo dal contenuto, salvare fuori dalla radice web, non eseguire mai |
| Controllo degli accessi difettoso | Gli utenti raggiungono dati non loro | Verificare l'autorizzazione lato server a ogni richiesta, non nell'interfaccia |
| Esposizione di dati sensibili | Fa trapelare chiavi e credenziali | Variabili d'ambiente, mai nel repository |
| Server-side request forgery | Fa chiamare al tuo server sistemi interni | Elenco di destinazioni in uscita consentite |
Configurazione e intestazioni#
Misure poco costose che chiudono intere categorie di problemi, quasi tutte applicabili in pochi minuti.
- Servi intestazioni di sicurezza: Content-Security-Policy, X-Content-Type-Options, Referrer-Policy, X-Frame-Options.
- Disattiva l'elenco delle directory; assicurati che /.git, /.env e i file di backup non siano raggiungibili via HTTP.
- Disattiva l'output dettagliato degli errori in produzione: le tracce di esecuzione sono ricognizione per l'attaccante.
- Blocca l'accesso ai percorsi di amministrazione e configurazione dalla rete pubblica dove puoi.
- Imposta i cookie con HttpOnly, Secure e un valore SameSite adeguato.
- Tieni le dipendenze verificate; una libreria vulnerabile nella tua build è una tua vulnerabilità.
- Registra gli eventi di autenticazione e allerta sugli schemi insoliti.
Se il sito è già compromesso#
Qui l'ordine conta. Ripulire i file prima di cambiare le credenziali significa che l'attaccante rientra semplicemente dalla stessa porta.
- Metti il sito offline o in modalità manutenzione. Non lasciarlo servire software dannoso ai visitatori.
- Conserva le prove: copia i registri e un'istantanea dei file prima di cambiare qualsiasi cosa.
- Cambia ogni credenziale: hosting, database, utenti di amministrazione, chiavi API, e-mail. Presumi che siano tutte note.
- Ripristina da un backup precedente alla compromissione, se riesci a individuarne uno in modo affidabile.
- Se non ci riesci, ricostruisci dai sorgenti e importa solo dati, mai file di origine ignota.
- Correggi la vulnerabilità che li ha fatti entrare. Senza questo passaggio ripeterai l'intero processo.
- Cerca la persistenza: attività pianificate, utenti di amministrazione aggiuntivi, file del nucleo modificati, contenuti iniettati.
- Richiedi una revisione in Search Console se il sito è stato segnalato, e cerca pagine di spam iniettate.
- Notifica gli utenti coinvolti se sono stati esposti dati personali — in molte giurisdizioni entro un termine di legge.
Ripristinare un backup senza chiudere il punto d'ingresso è il motivo più comune per cui i siti vengono compromessi due volte in quindici giorni.
Domande frequenti
Un plugin di sicurezza è sufficiente?
Aiuta su alcune cose — limitazione dei tentativi di accesso, sorveglianza delle modifiche ai file, un firewall di base — e non sostituisce aggiornamenti, credenziali robuste e privilegio minimo. Un sito con un plugin di sicurezza e diciotto mesi di aggiornamenti mancati non è sicuro. Sistema prima i fondamentali, poi aggiungi strumenti.
I siti piccoli vengono davvero attaccati?
Di continuo, e non per chi sei. Gli scanner automatici provano ogni host raggiungibile in cerca di vulnerabilità note; i siti piccoli sono attraenti proprio perché è meno probabile che siano aggiornati. I siti piccoli compromessi vengono usati per spam, pagine di phishing e reindirizzamenti, ed è per questo che il livello di traffico del tuo sito è irrilevante rispetto al rischio.
Dove vanno conservati i backup?
In un posto dove il server web non possa scrivere, idealmente presso un altro fornitore, con almeno una copia che le credenziali che fanno girare il sito non possano cancellare. I ransomware e gli attacchi distruttivi puntano proprio ai backup raggiungibili dalla macchina compromessa, ed è esattamente il momento in cui ti servono.
Qual è la misura di sicurezza di maggior valore?
Applicare gli aggiornamenti con prontezza. È poco spettacolare e previene più compromissioni reali di tutto il resto messo insieme, perché gli attacchi che avvengono davvero sono sfruttamenti automatizzati di vulnerabilità note e già corrette. Al secondo posto, l'autenticazione a due fattori sugli account di amministrazione e di hosting.
sicurezza sito websito web violatobuone pratiche sicurezzasql injectionxssbackup sito web
