Livello di sicurezza dei siti: cosa hanno mostrato 884 verifiche di Smart Audit

Un sito che si apre non è per questo un sito protetto. Il titolare vede la home page, il modulo d'ordine e il catalogo, e ne conclude che vada tutto bene. Ma una parte di ciò che accade a un sito si vede solo dall'esterno, con gli occhi di chi lo sta controllando.

Abbiamo lanciato il servizio Smart Audit, che guarda i siti altrui proprio così: in modo passivo, solo le pagine pubbliche. Non modifica nulla, non prova a indovinare le password e non entra all'interno. Al momento della preparazione di questo articolo avevamo i risultati di 884 siti aziendali unici: per ciascuno si considera l'ultima verifica andata a buon fine. Non abbiamo selezionato i casi «riusciti» o «falliti»: nel campione ci sono negozi online, siti aziendali, media e siti di grandi organizzazioni. Non citiamo nomi: ci interessa il quadro d'insieme, non i singoli indirizzi.

Qui di seguito: che cosa abbiamo visto, quali rischi comporta per il titolare e da dove cominciare a correggere.

Il quadro generale: 22 punti su 100

Il punteggio complessivo medio su tutti gli 884 siti è 22 su 100. Per singolo ambito: sicurezza 19, velocità 18, visibilità nei motori di ricerca 17.

• 480 siti (54%) hanno ottenuto meno di 20 punti su 100;
• 286 (32%) tra 20 e 39;
• 96 (11%) tra 40 e 59;
• solo 22 siti (2,5%) sono arrivati a 60 o più.

Guardando proprio al punteggio di sicurezza, il quadro è questo: per 466 siti (53%) è inferiore a 10 punti, per 652 (74%) è inferiore a 30, e solo 75 siti (8,5%) hanno ottenuto 60 o più.

Subito una precisazione, perché i numeri non vengano letti nel modo sbagliato. «22 su 100» non significa che il sito sia protetto al 22%, e tanto meno che sia stato violato. È la distanza da un insieme base di controlli: se il sito attiva o meno le protezioni che da tempo sono considerate la norma. La maggior parte dei punti si perde su aspetti che si correggono in fretta e con poca spesa. Ed è proprio per questo che vale la pena soffermarsi su questi numeri.

Primo livello: porte senza chiavistello

Ogni pagina che il server consegna al browser è accompagnata da «istruzioni» di servizio: che cosa è consentito a quella pagina e che cosa no. Sono i cosiddetti header di sicurezza. Non rendono il sito inattaccabile, ma attenuano il colpo quando si trova un'altra falla. E qui la carenza è quasi totale:

• La Content Security Policy (CSP) manca nel 90% dei siti. Stabilisce quali script il browser può eseguire nella pagina. Senza di essa, qualsiasi codice inserito di nascosto gira alla pari di quello «proprio». È così che nelle pagine di checkout compaiono gli skimmer: script che copiano di nascosto i dati delle carte bancarie. Per un negozio (e nel campione ne abbiamo 130) è il «chiavistello» mancante più costoso.
• La Permissions-Policy manca nel 93%. Limita ciò che i widget incorporati nel sito possono chiedere al visitatore: fotocamera, microfono, geolocalizzazione.
• La Referrer-Policy manca nell'88%. Senza di essa, gli indirizzi completi delle Sue pagine, compresi i numeri interni degli ordini o i token nei link, finiscono nei contatori e nei servizi pubblicitari di terzi.
• La protezione dall'incorporamento in frame altrui manca nel 73%. Un malintenzionato può mostrare il Suo sito in un frame trasparente sulla propria pagina e indurre la persona a cliccare un «pulsante» che in realtà si trova sul Suo sito. Questa tecnica si chiama clickjacking.
• Il divieto di «indovinare» il tipo di file manca nel 71% (nosniff).
• HSTS non è attivo nel 62%. Senza di esso, la prima visita di una persona può avvenire su un canale non cifrato, e in una rete Wi-Fi pubblica questo è un'occasione per sostituire la pagina.

Ad essere onesti: l'assenza di un header non significa un sito violato. Significa un livello di protezione mancante. Ma si corregge con poche righe nelle impostazioni del server, perciò la sua assenza dice quasi sempre una cosa sola: nessuno si è mai occupato delle impostazioni di sicurezza.

Secondo livello: ciò che è lasciato in bella vista

Questa sezione è più seria. In 172 siti su 884 (19%), quasi uno su cinque, sono accessibili dall'esterno indirizzi di servizio che non avrebbero mai dovuto essere pubblici. Alcuni siti hanno più di uno di questi punti contemporaneamente. Ripartizione per tipo:

• Elenco degli account WordPress: 103 siti (12%). L'indirizzo standard restituisce i login degli utenti, amministratori inclusi. Metà del lavoro dell'aggressore è già fatta: il login è noto, resta da indovinare la password.
• Cartella di servizio di Git: 45 siti (5%). Da essa si può ricostruire il codice sorgente del sito, e nella cronologia delle modifiche capita di trovare password e chiavi inserite «temporaneamente» nel codice.
• Pagina phpinfo: 43 siti (5%). Mostra le versioni di PHP, i moduli, i percorsi sul server, le variabili d'ambiente. Per chi attacca è una mappa del territorio già pronta.
• Pagina di servizio sullo stato del server: 34 siti (4%). Si vede quali indirizzi stanno aprendo i visitatori in questo momento e da quali IP.
• File di configurazione .env: 33 siti (4%). In un file simile di solito si trovano le password del database, le chiavi della posta e dei servizi di pagamento.
• Copia del database: 28 siti (3%). Un file che qualcuno ha lasciato nella radice del sito «solo per un attimo»: clienti, ordini, telefoni, indirizzi.

È importante capire che qui non c'è nulla da violare. Basta aprire l'indirizzo nel browser. Smart Audit non entra nel contenuto di questi file: si limita a registrare che a quell'indirizzo qualcosa risponde, mentre il contenuto non viene né letto né conservato. Ma ciò che non facciamo noi può farlo chiunque altro, e gli scanner automatici provano questi indirizzi giorno e notte in tutta la rete.

Terzo livello: software diventato obsoleto

Tra i siti verificati, il maggior numero è su WordPress: 222 (25%), seguito da OpenCart con 88 (10%). Per gli altri la piattaforma non è stata individuata oppure il sito è sviluppato «su misura».

154 siti (17%) rivelano da soli la versione del proprio sistema. Lo si vede nei marcatori di servizio della pagina. Di per sé non fanno danni: il danno nasce dalla combinazione con una versione vecchia. Tra quelli che hanno reso visibile la versione di WordPress, 22 siti funzionano sui rami 4 e 5, rilasciati molti anni fa. Per versioni del genere non conviene contare sul fatto che qualcuno chiuda le nuove vulnerabilità.

Un tema a parte è la versione del server stesso. In 247 siti (28%) gli header di risposta indicano le versioni esatte del software server. L'aggressore non deve indovinare: vede la versione e passa subito al metodo noto per quella versione. Quanto sia rilevante lo mostra l'esempio delle vulnerabilità critiche di PHP: lì l'unica difesa è l'aggiornamento tempestivo. Quanto al rovescio della medaglia, cioè che cosa succede quando l'aggiornamento avviene senza preparazione, ne abbiamo parlato nell'analisi dell'aggiornamento automatico di un plugin.

Quarto livello: moduli e connessioni, dove i dati dei clienti entrano nel sito

È attraverso i moduli che una persona Le trasmette nome, telefono, indirizzo, a volte il pagamento. Per questo il modo in cui sono costruiti conta più di tutto. Che cosa abbiamo trovato:

• 489 siti (55%): moduli senza protezione dalla falsificazione della richiesta (CSRF). Significa che una pagina estranea può far sì che il browser del Suo visitatore o del Suo amministratore invii il modulo a suo nome, senza chiederglielo.
• 543 (61%): moduli che raccolgono dati personali senza il consenso al loro trattamento. Non è solo una questione di sicurezza: riguarda anche il rispetto della normativa sui dati personali.
• 532 (60%): moduli senza protezione dai bot. La conseguenza è nota a chiunque abbia visto una casella di posta intasata dallo spam delle «richieste».
• 76 siti (9%): moduli che trasmettono dati personali nell'indirizzo della pagina (metodo GET). Telefono e nome restano nella cronologia del browser, nei log del server e finiscono in servizi di terzi insieme all'indirizzo.
• 321 (36%): cookie senza attributi di protezione. Sono più facili da intercettare o da leggere con uno script.

E alcune cose di base che, a rigore, dovrebbero essere presenti da tempo ovunque: 35 siti (4%) si aprono del tutto senza cifratura (il browser mostra l'avviso «Non sicuro»), in 43 il certificato scade a breve, e su 36 siti una parte del contenuto di una pagina protetta viene caricata su un canale non protetto, per cui la cifratura non è pienamente efficace.

Che cosa rischia il titolare

Lasciando da parte il gergo, i rischi per l'azienda sono pochi.

1. Fuga dei dati dei clienti. Una copia del database o un file di configurazione aperti non sono un «dettaglio tecnico», ma la possibilità di portarsi via l'elenco dei Suoi clienti senza violare nulla. Poi arrivano i danni di reputazione e la responsabilità per la custodia dei dati personali.
2. Codice estraneo sul Suo sito. Aggiornamenti non installati in tempo, più l'assenza di CSP: ed ecco comparire pubblicità di casinò, reindirizzamenti verso siti terzi o uno skimmer nella pagina di pagamento. Può scoprirlo da un cliente, e non da sé.
3. Etichetta «sito pericoloso» e calo nei risultati di ricerca. Browser e motori di ricerca non rischiano con i visitatori. Un sito violato può scivolare nei risultati per settimane, e risalire richiederà più tempo di quanto ne sia servito per perdere la posizione.
4. Fermo e costo del ripristino. Ripristinare dopo una violazione costa di solito molte volte di più di quanto sarebbe servito per la prevenzione. E finché il sito è fermo, non ci sono ordini.
5. Perdita di fiducia dei partner. Sempre più spesso i grandi clienti e i bandi chiedono di mostrare com'è messa l'azienda sul fronte della sicurezza. La risposta «non lo sappiamo» non fa guadagnare punti.

Da dove cominciare: l'ordine che funziona

1. Chiudere i file di servizio aperti. Sono le falle più costose, ma si correggono più in fretta: di solito basta un'ora di lavoro. I file con le password vanno tolti dall'accesso pubblico, e le password stesse poi cambiate, perché non si può ritenere che non siano trapelate.
2. Aggiornare il sistema e i plugin e togliere dalle risposte del server le versioni esatte. Aggiornare su una copia del sito, non alla cieca su quello in produzione.
3. Aggiungere gli header di sicurezza. Cominciare da HSTS, protezione dall'incorporamento, nosniff e Referrer-Policy: non rompono quasi mai nulla. La CSP va introdotta gradualmente, prima in modalità di osservazione.
4. Mettere in ordine HTTPS: rinnovo automatico del certificato, reindirizzamento da http, nessun contenuto non protetto.
5. Controllare i moduli: token contro la falsificazione della richiesta, protezione dai bot, trasmissione solo con il metodo POST, un consenso chiaro al trattamento dei dati.
6. Configurare copie di backup fuori dal sito e il monitoraggio. Una copia che sta accanto al sito, in caso di violazione sparisce insieme a lui. E la disponibilità del sito non deve verificarla il cliente.

Come aiutiamo

Smart Audit risponde alla domanda «che cosa non va, esattamente» nel linguaggio delle priorità: il report divide i risultati in quelli visibili subito e quelli insiti nella piattaforma stessa del sito. I primi li chiudiamo sul Suo sito attuale. I secondi, cioè versioni vecchie, limiti del sistema, impossibilità di configurare correttamente la protezione, di solito si risolvono con il passaggio al nostro sistema Smart CMS, dove header di sicurezza, protezione dei moduli e aggiornamenti sono già integrati alla base. Il passaggio lo eseguiamo noi: trasferiamo le pagine e gli indirizzi, manteniamo le impostazioni di visibilità nei motori di ricerca e La assistiamo a ogni fase, perché non perda né traffico né ordini.

Da qualunque punto decida di partire, prima conviene vedere il quadro del Suo sito.

---

Può verificare il Suo sito gratuitamente, senza registrazione, in tre minuti, su audit.sgt.com.ua. E se desidera che guardiamo il risultato insieme a Lei e Le diciamo senza giri di parole che cosa correggere per primo, ci scriva.