La gestione, progettazione o sviluppo di applicazioni web si concentra spesso sugli argomenti più importanti dal punto di vista dell'utilizzatore finale, come ad esempio l'usabilità dell'interfaccia, l'aspetto grafico ed estetico, la scelta delle tecnologie d'implementazione del frontend (HTML, JavaScript, jQuery ecc.) o di un framework di lavoro adatto all'esigenza.
Accanto a queste considerazioni entrano poi in gioco gli aspetti commerciali, l'analisi del mercato e l'osservazione dei trend di settore. Le scelte relative alle tecnologie di backend, come ad esempio l'interfaccia verso la base dati, sono spesso collocate all'ultimo posto o addirittura trascurate. Le uniche qualità che si chiedono ad un database, in molti casi, è di essere robusto, scalabile e gratuito.
Questo approccio è forse vantaggioso da un punto di vista commerciale, perché riduce i costi e diminuisce i tempi di sviluppo, ma rischia di trascurare un aspetto molto importante: la sicurezza dei dati memorizzati dall'applicazione. Abbiamo già visto qual è il meccanismo di criptazione che permette di salvare, in modo protetto, le password in un database.
Esistono però altre minacce alla sicurezza dei dati: uno dei pericoli principali è costituito dalle tecniche di SQL injections, che meritano una trattazione a parte. Per chi non sapesse di cosa stiamo parlando, l'SQL injections sono un insieme di tecniche che sfruttano i “canali pubblici di inserimento dati” per aprire qualche falla nel database, recuperare dati privati o provocare danni. I dettagli tecnici sono piuttosto complessi, ma il concetto è semplice: ogni volta che una pagina web contiene una form di inserimento dati (o simile), significa che l'utente ha la possibilità di inserire dati che verranno poi salvati nel database. L'esempio più banale è quello della form di registrazione di un nuovo utente, dove l'utente deve inserire nome, cognome, credenziali di accesso ecc.
Un processo di questo tipo implica che i dati inseriti dal cliente verranno trattati da una pagina web e poi scritti nel database, tipicamente mediante un'istruzione SQL di tipo INSERT. Una tecnica di SQL injections sfrutta questo meccanismo per inserire dati fasulli, che contengono al loro interno dei “caratteri speciali”, che una volta trattati e inseriti nel database fanno qualcosa di molto diverso da un semplice INSERT. Possiamo pensare ad una tecnica di SQL injections come ad una specie di bomba-carta: quando la missiva arriva all'ufficio postale (la pagina web), viene trattata come una normale lettera, dall'aspetto del tutto innocua. Ma quando la busta viene aperta, all'interno dell'ufficio (il database), il suo contenuto può provare danni più o meno gravi.
L'analogia è abbastanza accecata, perché suggerisce dove intervenire per eliminare il pericolo: gli attacchi di SQL injections andrebbero fermati prima di raggiungere il database, analizzando con attenzione la “busta” (i.e. la stringa inserita dall'utente nella form) e trattandola con alcune contro-tecniche in grado di rendere inoffensiva la minaccia. Esistono molte tecniche difensive, che però richiedono la conoscenza specifica di alcuni “trucchetti” sintattici per smascherare o disarmare l'aggressione. Un'alternativa è l'uso di qualche tecnologia ad hoc, che si occupi di disattivare le SQL injections per conto nostro. Una tecnologia di questo tipo è la libreria PDO_MYSQL per PHP, dove la sigla PDO sta per PHP Data Objects.
I vantaggi principali offerti dalla libreria sono:
- Possibilità di usare la libreria per accedere a diversi database, e non soltanto MySQL. Ciò permette di scrivere il codice PHP una volta sola, e di non doverlo cambiare nel caso di migrazione dei dati da un database ad un altro
- Protezione dalle tecniche di SQL injections più diffuse
- Leggero miglioramento delle performances
Per i dettagli relativi all'utilizzo pratico della libraria rimandiamo alla documentazione online di PHP. Lo scopo di questo articolo non è discutere nel dettaglio l'uso di PDO, ma fornire una visione a tutto tondo delle problematiche relative alla questione della sicurezza.
La sicurezza è un argomento da affrontare sotto prospettive diverse: occuparsi di un solo aspetto è un po' come blindare la porta di casa, lasciando aperta quella che conduce in garage. La scelta di una tecnologia come PDO è una buona pratica, ma solo se accompagnata da tutte le altre precauzioni del caso. Vediamo un esempio: supponiamo di aver protetto l'accesso al database con PDO, per ridurre i rischi di SQL injections, ma di non aver fatto nulla per limitare l'accesso ai files dove sono configurate le credenziali di accesso al database. Ogni pagina di un'applicazione web risiede da qualche parte sul web server, e in quanto tale è potenzialmente pubblica. E' perciò importante prendere delle precauzioni per limitarne l'accesso, ad esempio specificando delle regole in un file .htaccess, oppure inserendo dei controlli direttamente nel codice PHP, come discusso in questo articolo.
E' sorprendente vedere quante applicazioni a livello industriale, sia nazionale che internazionale, siano state realizzate con PDO, probabilmente allo scopo di aumentare la sicurezza, senza poi preoccuparsi di chiudere l'accesso ai files di configurazione. Per toccare con mano il problema basta copiare la seguente stringa in un motore di ricerca, e vedere cosa salta fuori
filetype:ini ”pdo_mysql” (pass|passwd|password|pwd)
Il risultato è inquietante: se cerchiamo (con un banale Ctrl + F) nelle pagine dei risultati le stringhe username o password, vedremo quante applicazioni sono presenti sul web in modo tutt'altro che sicuro. L'errore, in questo caso, è quello di usare PDO senza preoccuparsi anche di nascondere le risorse di configurazione della libreria.
Se non siamo tecnici esperti, quando scegliamo una soluzione di hosting dobbiamo valutare bene i vantaggi di un sistema gestito dall'hosting provider, anziché un sistema “aperto” che sembra (apparentemente) più vantaggioso solo perché costa meno, o perché ci vengono dati gli accessi incondizionati a tutti i componenti server. Questo dovrebbe essere uno dei numerosi vantaggi offerti dalle VPS di AziendeItalia, che sono tutte VPS managed: ciò significa che l'accesso al database, l'aggiornamento dei componenti software e quant'altro riguarda la gestione delle macchina remota viene delegato a persone esperte, riducendo di fatto i rischi e aumentando la sicurezza dei dati.
