Sicurezza e siti web: cosa significa, e perchè non devi sottovalutarla su internet?
È fatta! Un altro gran bel sito è pronto per il rilascio, e dietro all’eleganza di un interfaccia utente intuitiva e semplice, di un layout grafico efficace e lavorato al minimo dettaglio si nascondono migliaia di linee HTML, blocchi di codice Javascript con funzionalità innovative a base di AJAX, jQuery, magari mixati con un po’ di REST – e ancora, dal lato server, altre centinaia o migliaia di linee PHP, e tabelle SQL.
Tra te, il tuo sito ed il giusto compenso che renderà fattibili le agognate vacanze estive, il cliente e l’approvazione del sito. Il cliente che magari non è così a digiuno di IT in generale come cerca di dare a vedere, o forse lo è ma sa a chi appoggiarsi per le decisioni nel settore … la dimostrazione del sito prosegue senza perder colpi, fino alla domanda fatidica, una variazione qualunque sul tema di:
“Ma è sicuro il sito?”
Puoi dare una risposta che lasci tranquillo te sulla spiaggia, e tranquillo il tuo cliente alle prese con il suo nuovo investimento?
In questo articolo cercherò di aiutare a dare non solo risposte motivate, ma anche a fare in modo che queste risposte siano sincere e soddisfino i requisiti di sicurezza dei siti web. L’argomento sicurezza, in realtà, è estremamente più ampio, e copre in maniera uniforme tutto ciò che coinvolge i nostri dati sia in termini di danni mal intenzionati che quelli causati da guasti software o hardware o anche eventi catastrofici, ma qui ci concentreremo soprattutto sulla sicurezza nelle Rich Internet Application e nei siti web dinamici (per comodità indicherò tutto semplicemente come ‘siti web’ – molti siti odierni hanno complessità anche superiori alle RIA classiche) e su come rendere più solidi i siti web basati su Javascript, jQuery, JSON, Apache, PHP e SQL. Quindi, su come fare non solo per andarci, in vacanza, ma anche per godersele senza rischiare di ricevere sotto il sole il classico:
“Ma ci sono foto sconce in home page!”
Concetti di base
Per prima cosa, sgombriamo il campo dalla domanda numero 1. È possibile avere un sito sicuro al 100%?
La risposta è la prima legge della sicurezza: no, non è possibile. Posso avere un sito sicuro al 100% ora, ma dopo non lo sarà, vuoi perché qualche genio in qualche parte del mondo scoprirà un nuovo modo per infrangere la security del server web, o perché un trojan nella struttura del cliente aprirà un passaggio da cui qualche pirata preleverà, tra gli altri files, anche le password del backoffice del sito che qualche impiegato distratto avrà memorizzato in un file di testo sul desktop. O anche, molto banalmente, letta sul postit attaccato vicino alla tastiera sempre dal medesimo impiegato. Distratto, o anche malintenzionato: mai escludere nulla e nessuno.
Il primo concetto è lampante: la sicurezza del tuo sito è una catena molto, molto lunga, che comprende solo in parte la tua opera, ma anche strutture e personale:
- il lato utente, ovvero quello che il navigatore carica: HTML, CSS, Javascript, all’interno del browser che utilizza (Firefox, IE, Chrome, etc) e del sistema operativo (Windows, OS/X, etc);
- la rete internet, con tutti i punti di raccolta, i gateway, ovvero dove le nostre richieste HTTP viaggiano;
- la web farm, dove il nostro sito risiede fisicamente, tutti i files PHP, tutti i database;
- il lato del cliente: se l’applicazione ha un backoffice che permette al nostro cliente di gestire i database, o scrivere i testi, o scaricare immagini … anche questo diventa un anello della nostra catena.
Ovunque esista una macchina ad accesso in rete, hai un possibile punto d’attacco tecnologico, basato su sicurezza di rete che lascia a desiderare, bugs software nuovi o vecchi e mai corretti (un caso molto comune al giorno d’oggi, dove i tagli di budget colpiscono senza pietà anche le fondamenta stesse di qualunque reparto IT), possibili intrusioni hardware.
Ovunque esista personale, non importa se dirigenti, impiegati o personale di servizio, hai un possibile punto d’attacco sociale, basato sul phishing, o su banalissima ingegneria dei rapporti umani che permette di carpire password a volte molto riservate … semplicemente chiedendole al telefono. O sbirciando dietro la foto sulla scrivania, o sotto al mouse, o scritte in corpo 24 sull’etichetta del monitor LCD, o banalmente intuibili …
L’integrità della catena è compromessa quando anche uno solo degli anelli viene compromesso. E da qui si ricava la seconda legge della sicurezza:
la sicurezza di tutta la catena è pari alla sicurezza dell’anello più debole.
Quindi: la catena è attaccabile in tutti i suoi punti ed in tutti i modi, tecnologici quanto sociali, con vari gradi di resistenza all’attacco. Alcuni sono assolutamente imprevedibili ed inevitabili, o impraticabili, ragione per cui un sito non sarà mai sicuro al 100%! E come sviluppatore web, puoi ben poco contro una buona parte di quei problemi.
Ma questo non significa lasciar perdere del tutto il problema: tutt’altro! Hai tre compiti:
- creare un sito che non presti il fianco ad attacchi tecnologici – di questo parleremo dopo, e molto approfonditamente;
- coinvolgere il cliente nel problema, assicurarsi che capisca gli attacchi sociali e sappia gestirli: se la nostra applicazione genera o usa password, non transigere sulla qualità delle password: le password ‘uguali per tutti’ non sono accettabili (oltre che, per i discorsi di tutela della privacy, illegali)! Che sappia e sia reso responsabile dei rischi che corrono i suoi dati: gli stessi che correrebbe se tutte le automobili come la sua avessero la stessa chiave;
- preparare le risorse e gli strumenti nel caso dovesse succedere il peggio: copie del sito nelle varie versioni, backup, configurazioni, tool e materiali forensici – anche questo sarà argomento di discussione. E preparare anche le spiegazioni da fornire al cliente, quando necessario.
E se non lo fai? A parte il rischio, quasi certezza, di perdere un cliente magari importante in caso di problemi, potresti essere considerato come parte in causa, potresti non essere in grado di dimostrare di aver fatto del tuo meglio – perchè magari il tuo sito potrebbe essere usato come cavallo di troia per aver accesso a parti ben più critiche e riservate, e questo magari per un banalissimo
$h = popen("zip -r 9 $file", "r");
mal gestito all’interno di uno nei nostri php.
Come parlarne con il cliente?
È assolutamente necessario mantenere sin da principio un rapporto sincero con il cliente, ma allo stesso tempo essere forti sui propri argomenti. Il concetto che un sito non sia mai sicuro al 100% spaventa – ma la stessa cosa vale per un negozio, un automobile lasciata in un parcheggio, un appartamento, ancora di più se parliamo di banche, automobili di lusso e ville – in diretta proporzione. Nessuno rinuncia a comprare un automobile solo per il rischio che possa essere rubata: semmai, ci si preoccupa di custodire le chiavi, di parcheggiarla in un posto sicuro e di assicurarla!
Così come un antifurto in casa dissuade e scaccia, ma non da sicurezza assoluta, allo stesso modo la sicurezza su web dissuade e scaccia – e a differenza, ahimè, dei soldi nascosti in banca, noi possiamo effettivamente fare backup estremamente sicuri per permetterci, perlomeno, di ripristinare quanto danneggiato in tempi rapidi. Su questo, il cliente deve essere rassicurato.
In molti casi, il cliente capirà e sarà disposto a partecipare alla gestione della sicurezza. In altri lo sarà di meno, e le questioni che solleverà saranno una variazione su questi temi:
- “Non mi è mai successo!”
- “Non ci conosce nessuno – è un url che non si conosce!”
- “Non c’è nulla di valore nel sito!”
- “Non possiamo ricordarci tutte queste password strane!”
Temi che dobbiamo saper affrontare dimostrando di conoscere le risposte:
- non perché non è mai successo, significa che non possa succedere! È proprio sottostimando il pericolo che si causano i danni peggiori;
- i link si diffondono molto in fretta, non importa chi sei: grande o piccolo, sei sempre e comunque interessante per il fatto di avere uno spazio su web utilizzabile per altri scopi. Anzi: se proprio sei piccolo, sei interessante perché sei meno ‘potente’ dei grandi nomi, che possono permettersi di scatenare armate di avvocati da fare tremare la terra;
- lo spazio web, i dettagli dei clienti, la tua immagine ed il tuo marchio sono elementi di valore – puoi immaginare che effetto farebbe se accanto al tuo nome apparisse materiale, per così dire, ad alta risoluzione e colorito nei contenuti?
- le password sono l’equivalente delle chiavi – la complessità, nonché la frequenza con cui le cambiamo e la cura con cui le custodiamo le mantengono sicure.
Nel prossimo articolo, inizieremo ad esaminare la struttura completa di un sito web attraverso tutte le sue parti, come se fosse una casa e dovessimo valutarne la sicurezza osservando finestre, porte, serrature, muri e le facce di postini e addetti alla lettura del contatore.
Ma prima di allora, parliamo …
Nei tuoi progetti, come hai affrontato il problema sicurezza di fronte ai clienti? Hai mai dovuto gestire situazioni di emergenza?
L'autore
Articoli correlati
Potresti essere interessato anche ai seguenti articoli:
26 commenti
Trackback e pingback
-
Sicurezza e siti web: cosa si nasconde dietro al tuo sito? | Your Inspiration Web
[...] nello sviluppo dei nostri siti web, non importa quanto siano complessi o chi li ha commissionati (“Sicurezza e siti… -
Sicurezza e siti web: code injection | Your Inspiration Web
[...] Cosa significa, e perchè non devi sottovalutarla su internet? [...] -
Sicurezza e siti web: come trovare le cause di code injection, tecniche di validazione | Your Inspiration Web
[...] Cosa significa, e perchè non devi sottovalutarla su internet? [...] -
Sirecurezza e siti web: code injection, escaping ed indirezione | Your Inspiration Web
[...] Cosa significa, e perchè non devi sottovalutarla su internet? [...]
Ovviamente gli aspetti sono tanti. Ne porto uno solo per aprire la discussione:
il costante aggiornamento dei software.
Questo aspetto, ad esempio, mi ha portato spesso a scegliere WordPress invece di Joomla come CMS utilizzato, in quanto il primo è molto più facile da gestire sotto questo aspetto. La possibilità di avere un avviso della disponibilità di una nuova versione del software o di un suo plugin lo ritengo un aspetto importante. A parità di sicurezza iniziale infatti, ho ritenuto che il primo mi dia più garanzie a lungo termine del secondo.
Ciao Roberto. Si, ci sono innumerevoli aspetti, anche se ci limitiamo al solo sviluppo web, ed è per questo che la strategia migliore è sempre quella non solo di saper prevenire i problemi, ma anche quella di sapere ripristinare in caso i problemi siano, ahimè, avvenuti. È impensabile riuscire ad anticipare sempre e tutto!
Sugli aggiornamenti software, io sono dell’idea che più che essere frequenti e numerosi, rendendo la vita difficile a chi deve gestirli, debbano essere tempestivi e di applicazione immediata, in modo da incoraggiarne l’installazione.
Pensa ad esempio a Firefox, che scarica gli update e si auto aggiorna – dopo richiesta di farlo, come deve essere – così come auto aggiorna i suoi plugin arrivano persino a disabilitarli se vengono considerati pericolosi: in questo caso sembra persino “strano” il non aggiornare.
Considera invece i software di vecchio stampo, dove dovevi cercarti gli aggiornamenti a occhio, scaricarsi magari anche dieci patch, installarle e sperare che tutto funzionasse anche dopo … era chiaro che un approccio di questo genere era meno “attraente”, e come tale lasciava spesso programmi e sistemi operativi vulnerabili per lungo tempo.
perche paragonare una state-of-the-art publishing platform ad un qualsiasi (molto) piu vecchio ContentManagementSystem?
Leggo in questo momento l’articolo di Cristian dopo che “badAboy albania…..”
ci ha “bucato” il server ed infettato tutti i nostri siti in Joomla! un vero disastro…..
una brutta sensazione al quanto difficile da spiegare, che ti lascia un vuoto dentro.
Oggi mi sono buttato su wordpress ma non è la stessa cosa.
Ne approfitto per dare il benvenuto ufficiale a Cristian, nostro nuovo autore che esordisce su YIW con questa splendida guida dedicata alla sicurezza.
Complimenti per l’articolo Cristian e per come sei riuscito a parlare di un argomento così tecnico e difficile in modo leggero e divertente. Adoro la sottile ironia di fondo che hai utilizzato.
Per quanto riguarda la tua domanda finale, fortunatamente gli unici attacchi di cui sono stato vittima al momento riguardano l’utilizzo di script Open Source sui quali è molto più facile subire aggressioni.
Sono d’accordo con quanto detto da Roberto, quando si sceglie di utilizzare uno script Open Source è fondamentale valutarrne anche la frequenza e la modalità di segnalazione degli aggiornamenti, cosa spesso sottovalutata.
Ti ringrazio Nando, spero di riuscire a mantenere il livello sul buono …
È vero, gli script d’uso comune sono i più suscettibili ad attacchi, in questo caso molto spesso attacchi automatici che si basano sui nomi dei files utilizzati o su altre tracce che si possono facilmente cercare all’interno dei files html (o, spesso, persino tramite Google!). Una possibile tecnica per diminuire questo genere di problemi è installarli fuori dalla loro directory di default o, dove possibile, con nomi diversi da quelli di default.
Questo normalmente elimina gli attacchi automatici, cioè basati su script che lanciano metodicamente url corrispondenti a bug su script su centinaia o migliaia di siti ogni ora: con la speranza, che è praticamente una certezza, di inciampare prima o poi in qualche buco.
Benvenuto nel team, Cristian :)
Dalla grandissima capacita’ di autoironia presente in questo articolo ci sono tutti i presupposti perche’ tu possa trovarti benissimo in questa famiglia di pazzi che e’ YIW!
Grazie per il benvenuto!
Sull’ironia non ho dubbi: chiunque abbia fatto un mestiere (uno qualunque) nell’IT per più d’un paio d’anni la sviluppa come anticorpi alla follia del mondo in cui s’immerge :)
In realtà, sembriamo pazzi, ma solo perché l’abbinamento tra logica matematica ferrea e fantasia visionaria illimitata con cui dobbiamo destreggiarci nel mondo del web è talmente inusuale nel mondo di terra e cielo da essere ritenuto fuori dalla portata dei sani di mente – dunque, pazzo tra pazzi!
Ciao Cristian, un caloroso benvenuto anche da parte mia nella redazione di YIW (quando te ne pentirai sarà troppo tardi).
Ho avuto un problema l’anno scorso (forse l’ho già raccontato). Si è trattato di un caso di sabotaggio industriale (non dimostrabile, ma la tempistica ed anche una piccola soffiata non lasciano dubbi).
Il cliente era sul punto di concludere un importante affare quando il sito (in Joomla) viene bloccato da google con un avviso tipo: “sito pieno di malware”. Segnalate decine di pagine infette, ma non mi risultava. Fino a che ho pensato: “Vuoi vedere che mi hanno bucato il file del template?”
Infatti era pieno di frammenti di javascript.
Il problema è che una volta sistemato il tutto, tu fai l’annuncio a google, e quelli ci mettono un mese a vedere se è davvero tutto ok. Questo per dire come a disastro poi si somma un altro disastro.
P.S L’articolo è veramente molto bello
Già … i motori di ricerca sono sempre un’arma a doppio taglio: da una parte, aiutano a trovare eventuali problemi al sito, dall’altra li espongono al mondo … i CMS moltiplicano i problemi di questo genere proprio perché pubblici, ben conosciuti ed usati spesso anche da chi ha meno dimistichezza già con l’html e ancor meno con le problematiche di sicurezza collegate, quindi diventano obiettivi molto appetibili.
Wait, I cannot fathom it being so straigfhtroward.
Benvenuto Cristian! :D
Complimenti per l’articolo e neanche a farlo apposta, proprio ieri ho subito un attacco hacker su un sito che ho fatto qualche mese fa, ma non so se è per via del server web o del sito, non ho molte possibilità di vedere… il sito non è niente di eccezionale, è solo un semplice sito statico, quindi presumo abbiano sfruttato qualche buco del server web.
Ecco, quello è esattamente la situazione tipica in cui finiamo come sviluppatori web: in realtà siamo solo un punto di una catena molto lunga, di cui parlerò nella prossima parte. Il problema è che siamo la parte terminale, e quindi finiamo sempre per essere i primi accusati, ed in molti casi è persino difficile discolparsi proprio perché è davvero complesso spiegare tutto quello che c’è dietro, in termini di hardware e di software ad un “semplice sito statico”.
Ciao Cristian, ti dò il benvenuto anch’io a YIW !!!
Veramente un bellissimo articolo che tratta molto bene un’argomento davvero interessante !!!
Complimenti :)
Ciao, ti ringrazio per i complimenti – spero le parti successive siano di altrettanto interesse!
Costruendo siti in joomla sono stato defacciato spesso e volentieri. Le copie di backup del DB e dei file le ho imparate a farle a mia spese dopo varie chiamate dei clienti. E sempre a mie spese ho imparato a fare tutto il possibile per rendere questo cms più “sicuro”…
anche se joomla è più nell’occhio del ciclone rispetto ad altri cms è anche vero che con le opportune misure di sicurezza torna ad essere al livello degli altri (da questo punto di vista).
Ciao Michele.
Purtroppo, la probabilità di avere problemi di questo genere cresce molto rapidamente se ai nostri siti web andiamo ad aggiungere grossi blocchi di codice esterno fuori dal nostro controllo, perché andiamo ad aggiungere un altro anello in una catena di oggetti e persone “corrompibili” già lunga e complessa di per se (di cui parleremo presto). Questo vale per ogni CMS.
Il brutto, è che molti clienti vedranno nei problemi del loro sito un problema di tue mancanze, non un problema ad una parte che non è molto sotto tuo controllo, perché faranno fatica a vedere la differenza tra il tuo contributo e quello del CMS: qui deve sempre entrare in gioco la parte diplomatica nel nostro mestiere già al momento della presentazione del progetto.
In questi contesti si impara molto rapidamente il concetto di “se non puoi difendere, sorveglia e ripristina”, e quello altrettanto importante di seguire con puntiglio gli update, seguendo sempre con la massima attenzione quelli che riguardano il campo della sicurezza.
Imparare a difendersi con accorgimenti aggiuntivi, come scrivi, è davvero un’ottima arma in più, molto spesso decisiva contro gli attacchi automatizzati dove il tuo sito è aggredito da uno script predisposto ad aggredire le installazioni standard: le tue modifiche molto spesso lo sposteranno fuori quel tanto che è basta (sebbene, ahimè, non sempre: ma abbiamo già diminuito le probabilità!)
Bell’articolo complimenti! Concordo pienamente su tutto! Specie nel punto in cui dici “Non ci conosce nessuno – è un url che non si conosce!”. Non poco tempo fa ho trovato una piccola ditta con circa 40 siti in portfolio dove si entra nel backend con un SQL Injenction banalissimo o peggio ancora nome: demo, pass: demo… ma si puo’ fare un lavoro del genere? e si definiscono anche “professionisti” del settore… Io odio queste cose perche’ si faranno pagare il sito migliaia di euro perche’ hanno un “CMS proprietario” e usano paroloni per farsi belli con i clienti e poi fanno di quei lavori da brivido!!!
Ciao Luca.
Il modo delle web agencies è un Giano, se non un Hydra … molto spesso, la testa dominante è quella commerciale, che emerge dalle parole altisonanti, si innalza d’iperboli e metafore, e crolla miseramente sotto il peso di implementazioni insufficienti dovute, molto spesso, all’utilizzo di risorse a basso costo e scarsa esperienza: queste devono andare a confrontarsi con l’aggressività del cracker professionista, che è come andare sul ring e trovarsi di fronte un pugile professionista senza mai essere entrati in palestra prima … son botte da orbi!
A volte hanno anche una fortuna incredibile, ed in quella che è la roulette dell’aggressione non vengono mai estratti e magari campano per anni senza problemi. Ma basta che succeda una volta, e che divengano bersaglio di anche uno solo che individui l’obiettivo succulento …
Il brutto è che, purtroppo, devi competere con loro, ed il cliente non ha nè gli strumenti, nè il tempo nè tantomeno l’idea di verificare cose come quelle che hai individuato tu, e molto spesso si lascerà convincere da parole magiche, acronimi da settimana enigmistica e citazioni zuccherose …
Mamma mia che modo particolare di scrivere che hai! mi piace!
Hai pienamente ragione, come ti dicevo la cosa mi urta non poco e credimi che la tentazione di buttargli giu’ il sito e’ forte perche’ una volta “scottati” allora non ripeteranno l’errore, ma so gia’ che non lo faro’ perche’ so quanto lavoro c’e’ dietro e non si puo’ penalizzare una “svista”, mandero’ loro una mail e loro mi ringrazieranno con un semplice “grazie, provvederemo quanto prima”. Si grazie, ringrazia di non aver fatto una figuraccia davanti a 40 clienti! Ciao grande!
bell’articolo,
potrebbe essere utile un articolo in cui si parla della sicurezza nell’accoppiata jquery-php nelle query delicate di cancellazione e update…
magari parlare di qualche metodo che permetta di rendere sicura la querystring passata tramite jquery, in modo che nessuno possa inserirla nella barra degli indirizzi e fare le operazioni che preferisce cambiando i valori delle variabili.
Grazie mille