I database e i dati ivi contenuti sono tra obiettivi più perseguiti dai cracker, sempre alla ricerca del modo per sfruttare i molti punti deboli presenti nelle applicazioni database-driven. Molti di questi punti deboli sono frutto di configurazioni o implementazioni discutibili.
Fra le vulnerabilità inerenti i database, le seguenti cinque sono probabilmente le più comuni:
- Policy delle password mediocri
- SQL injection
- Cross site scripting
- Perdita di dati
- Gestione impropria degli errori
Anche se può sembrare incredibile, per proteggere un asset online importante come un database spesso nelle imprese sono ancora usate password di default o facilmente indovinabili. Questo è però un problema semplice da risolvere: il rimedio sta nel far rispettare una forte policy, che preveda che le password debbano essere cambiate regolarmente, che debbano essere lunghe almeno 10 caratteri e che contengano un insieme di simboli e caratteri alfanumerici.
Anche l’SQL injection sfrutta una carente implementazione del database, in particolare sul modo in cui le query SQL sono trasmesse al database. Se quest’ultimo accetta query SQL su dati forniti dall’utente senza che questi siano stati “puliti” e validati automaticamente, è possibile sferrare un attacco SQL injection. Per esempio, modificando l’input ricevuto tramite un form Web based, un attacker può attivare query SQL maligne e inviare comandi direttamente al database.
Per impedire questo tipo di attacco, è essenziale accertarsi che tutti i dati forniti dall’utente siano validati prima che vengano gestiti dai vostri script, dalle routine di accesso e dalle query SQL. Inoltre, privilegiate l’uso di query parametrizzate.
Un altro motivo per validare e “pulire” i dati ricevuti dagli utenti è la difesa dagli attacchi di Cross site scripting (XSS) , che possono essere usati per compromettere un database collegato a un server Web. Tali attacchi agiscono inserendo uno script lato client, quale un Javascript, nell’output dell’applicazione Web attraverso un form Web. Questi script sono impiegati per raccogliere i dati presenti nei cookie, che spesso sono usati in modo errato per memorizzare informazioni come i login degli account dell’utente.
Un problema spesso trascurato quando si sviluppa un’applicazione database è la perdita di dati , intesa come il trasferimento involontario o la mancanza di disponibilità di dati sensibili. L’errore più classico sta nel non riuscire ad assicurare e controllare l’accesso ai tape di backup del database. Una perdita meno frequente avviene attraverso un’interpretazione logica dei dati. Spesso, i dati più sensibili possono essere arguiti dalle risposte a determinate query, come nel caso di una malattia che viene dedotta dai farmaci prescritti. Una semplice soluzione sta controllare i pattern delle query per rilevare tale attività.
Collegata strettamente alla perdita di dati è la manipolazione impropria degli errori quando questi si verificano all’interno del database. Molte applicazioni visualizzano messaggi dettagliati che possono fornire informazioni sulla struttura del database, ma che a volte possono essere usati per organizzare degli attacchi. Comunque sia, annotate sempre l’errore per tenerne traccia all’interno di uno storico, ma assicuratevi che la vostra applicazione non restituisca agli utenti (o agli attacker) alcuno specifico particolare circa l’errore in questione.
Per cercare di rendere più sicuro il database, dividete l’operazione nelle seguenti quattro aree al fine di avere un controllo completo:
- Sicurezza del server
- Sicurezza dell’applicazione
- Collegamenti al database
- Controllo dell’accesso alla tabella e al database
Un database server deve essere potenziato come qualunque altro server per accertarsi che i cracker non possano sferrare un attacco attraverso le vulnerabilità del sistema operativo. Preferibilmente, il database dovrebbe essere posto dietro il firewall.
Per favorire il processo volto a rendere sicuri i collegamenti al database e a definire i comandi di accesso, create un diagramma di flusso che tenga traccia di come i dati vegano usati dall’applicazione. Quindi, identificate i punti di ingresso dei dati o di uscita verso un’altra applicazione, verificandone i livelli di sicurezza. Inoltre, stabilite i privilegi minimi per ogni utente esterno o i processi richiesti per accedere al sistema.
