Informatica - La Sicurezza di Andrea Balzano 5M

Informatica
“La sicurezza dei database"
Requisiti di sicurezza
Per garantire la sicurezza di un database vengono gestiti dei requisiti che sono alla base della
protezione di un database.
L’integrità del database; gli utenti devono potersi fidare dell'accuratezza dei valori dei dati, per cui
gli aggiornamenti devono essere fatti solo attraverso singole autorizzazioni e i dati devono essere
protetti sia dall'azione di programmi esterni illegali sia da forze esterne come calamità naturali.
L'integrità del database è completa responsabilità del DBMS, del sistema operativo, e del manager
di sistema. Una forma di protezione del database, quindi, può essere data da un regolare backup
di tutti i file del sistema.
L’integrità degli elementi; in un database ci si riferisce alla loro correttezza e alla loro accuratezza.
Gli utenti autorizzati sono responsabili dell'introduzione corretta dei dati, ma essi spesso possono
commettere errori durante l’immissione, infatti il DBMS aiuta gli utenti a trovare l’errore appena
immesso e a correggere gli errori già inseriti grazie a dei controlli di campo. Un controllo di campo
può essere un valore numerico, una lettera maiuscola, o uno specifico carattere, questo controllo
assicura che un valore cada in specifici limiti, prevenendo così errori di distrazione durante
l’immissione dei dati.
Un altro metodo per garantire maggiore sicurezza è il controllo degli accessi, che aiuta a garantire
l'integrità dei dati e protegge i database. E’ necessario quindi assegnare agli utenti autorizzazioni
di condivisione per ciascun database utilizzato. Le autorizzazioni di condivisione vengono concesse
in modo tale da consentire solo agli amministratori del database di accedere ai file che controllano
il database. Tutti gli altri utenti non sono autorizzati ad accedere a questi file. Inoltre il numero
delle modalità di accesso può essere elevato, ossia un utente o un programma potrebbe avere il
diritto di leggere, modificare o eliminare un dato, oppure riorganizzare l’intero database.
L'amministratore del database di un team è responsabile della protezione, ovvero del blocco dei
database condivisi del team. Solo i membri del gruppo definito dagli amministratori possono
eseguire operazioni di amministrazione del database. L'amministratore del database deve
assegnare a tutti gli utenti, incluso se stesso, le autorizzazioni di condivisione del database
appropriate per limitare in modo adeguato l'accesso alle condivisioni di rete. Deve inoltre
assegnare a tutti gli utenti del database diritti specifici per ogni progetto che dovranno utilizzare.
Quando si parla di verificabilità del database, ci si riferisce a un record di verifica di tutti gli
accessi, questo record aiuta a mantenere l’integrità del database indicando chi ha modificato
determinati dati e quando è avvenuta la modifica. Un altro vantaggio di questo metodo di
protezione è il fatto che gli utenti possono accedere in modo incrementale ai dati protetti, ossia
solo una serie di accessi sequenziali visualizzati insieme mostrerà i dati. Grazie al DBMS possono
essere aggiunte al database nuove categorie di dati senza dover stravolgere il sistema esistente. Il
sistema di sicurezza dei dati impedisce agli utenti non autorizzati di visualizzare o aggiornare il
database. Mediante l'uso dell’autenticazione dell’utente agli utenti è permesso l'accesso all'intero
database o ad un suo sottoinsieme.
I sistemi di database sono spesso sistemi multi-utente, quindi l’accesso di più persone nello
stesso database deve essere quindi vincolato, in modo di non creare problemi di interferenza. Il
DBMS può mantenere l'integrità del database non consentendo a più utenti di modificare lo stesso
record contemporaneamente (blocco del record) e può impedire l'immissione di due record
duplicati. Un ulteriore problema dell’accesso concorrente è la lettura/scrittura. Ad esempio se un
utente sta aggiornando un valore, mentre un altro desidera leggerlo, il lettore potrebbe ricevere
dati aggiornati parzialmente, di conseguenza il DBMS blocca le richieste di lettura fino a quando
non viene completata la scrittura.
Affidabilità del database
I database sono un insieme di dati provenienti da varie fonti. Gli utenti affidano i propri dati ad un
DBMS e si aspettano la loro protezione da perdite e danneggiamenti. Le questioni riguardanti
l’affidabilità e l’integrità sono problemi di protezione generici, il DBMS utilizza diversi metodi per
evitare perdite o danni ai dati. Per questo motivo i file del database sono spesso sottoposti a
backup periodici, un'altra tecnica per mantenere integri i dati custoditi all’ interno del database è
l’aggiornamento in due fasi, questo aggiornamento è chiamato così, perché consiste di due fasi.
Con questa tecnica durante la prima fase, il DBMS raccoglie le informazioni e le risorse di cui ha
bisogno per eseguire l'aggiornamento ma non fa cambiamenti permanenti. Se il sistema fallisce
durante la prima fase, può essere fatta ripartire senza problemi. L'ultimo evento della prima fase è
chiamata operazione di commit in cui si scrive un flag di conferma nel database. Questo flag indica
che il DBMS supera un punto di non ritorno e dopo il commit, si comincia a fare cambiamenti
permanenti. La seconda fase fa cambiamenti permanenti. Durante questa fase nessun'azione
prima del commit può essere ripetuta, ma le attività di aggiornamento della seconda fase possono
essere anche ripetute, come spesso è necessario. Se il sistema fallisce durante la seconda fase, il
database può contenere dati incompleti, ma questi dati possono essere corretti rifacendo tutte le
attività della seconda fase.
Per garantire l’affidabilità di un database viene spesso usato un codice di rilevamento e correzione
degli errori. Molto spesso si utilizzano tecniche come: bit di parità, codice di Hamming, e codici di
ridondanza ciclica. Quando un record viene memorizzato in un database, i codici di controllo
vengono elaborati e archiviati, quando questo dato viene utilizzato, si elabora un codice di
controllo simile, che viene confrontato con il valore memorizzato inizialmente. Se i valori sono
diversi, allora nel database si è verificato un errore. Un altro strumento per verificare i valori
inseriti è il monitor. Un monitor è un'unità di un DBMS che è responsabile dell'integrità
strutturale del database, esso può controllare valori inseriti per assicurare la loro consistenza con
il resto del database. Un esempio di monitor è il monitor per la comparazione di range testa ogni
nuovo valore per assicurare che questo valore è all'interno di un range accettabile. Se il dato è al di
fuori del range, esso viene rifiutato e non inserito nel database.
Un altro problema di sicurezza dei database è la sensibilità dei dati, infatti un database può
contenere dati sensibili, dati che non dovrebbero essere resi pubblici. Molti fattori possono
determinare la sensibilità dei dati. Un dato può essere dichiarato sensibile, o può essere sensibile
per il valore che esso contiene. A volte la sola esistenza di un dato può rivelare sensibilità; in altri
casi un dato può diventare sensibile solo in presenza di altri dati. Quando un database contiene dei
dati sensibili, questi dati possono essere controllati grazie a dei permessi di accesso. Quando in
uno stesso database convivono dati sensibili e dati non sensibili, si limita l'accesso degli utenti in
modo che possano ottenere solo i dati di loro pertinenza.
Per questo si parla di politica degli accessi, in pratica è l’amministratore del database che decide
chi ha diritto ad accedere a questi dati. Per permettere l’accesso a questi dati il DBMS considera
vari fattori:
La disponibilità dei dati, ossia quando un dato non è aggiornato, per tutta la durata
dell'aggiornamento esso non dovrebbe essere disponibile, per evitare l'inconsistenza di altri dati.
L’ accettabilità degli accessi: il DBMS, nel decidere su un accesso, non deve rilasciare dati sensibili
ad utenti non autorizzati.
Autenticità degli utenti ossia permettere l'accesso al database solo in determinati periodi di
tempo.
Altri problemi di sicurezza sono: l’ inferenza, cioè la deduzione di dati sensibili da dati non
sensibili; l’attacco diretto cioè quando si tenta di determinare valori di campi sensibili cercandoli
direttamente con query che producano pochi record; l’ attacco indiretto che rilascia soltanto
statistiche, con questo attacco sono eliminati nomi individuali, indirizzi o le altre caratteristiche
dalle quali può essere riconosciuto un singolo individuo e rilasciate solo statistiche neutrali, come
somme, contatori e medie. L'attacco indiretto cerca di dedurre un risultato basato su uno o più
risultati statistici. Un altro tipo di attacco è l’attacco del segugio, questo attacco del può ingannare
il DBMS localizzando i dati desiderati con l'utilizzo di query supplementari che producono come
risultati un numero basso di record. Questo attacco aggiunge record supplementari che sono
recuperati da due query diverse; le due collezioni di record si annullano a vicenda lasciando
solamente la statistica desiderata.
Ci sono essenzialmente due modi per proteggersi contro attacchi di inferenza: la soppressione e
l'occultamento. Con la soppressione i dati sensibili non sono forniti, la query è negata senza
risposta. Con l'occultamento la risposta fornita è simile ma non è esattamente il valore attuale. Un
altro controllo combina righe e colonne per proteggere valori sensibili, e un ulteriore metodo che
combina i risultati è l'arrotondamento, ossia i valori attuali sono arrotondati per eccesso o per
difetto al più vicino multiplo della rispettiva base.
Un altro controllo statistico è disturbare i valori di un database con piccoli errori. Se x i è un valore
corretto dell'elemento i del database, ei è un piccolo errore casuale aggiunto a xi per risultati
statistici. Il valore e è sia positivo che negativo, in modo che i valori restituiti possono essere sia
più alti sia più bassi del valore corretto.
Un altro metodo di sicurezza sicuramente più complesso è l’analisi della query, ossia viene
analizzata una query per dedurre se il risultato può essere fornito dal database oppure no.
Un tipico attacco: SQL Injection
I database rappresentano il luogo dove vengono custodite le informazioni e per la loro natura
costituiscono spesso la parte più importante nella realizzazione di un progetto. E' facile quindi
intuire perché gli hackers sono attratti da questi sistemi, in quanto contengono informazioni
spesso di natura confidenziale come numeri di carte di credito, dati personali, dati di natura
finanziaria ecc.... Spesso chi attacca è molto più affascinato dal fatto che un database è un
elemento importante nel funzionamento di una applicazione e quindi richiede alte misure di
sicurezza, poter bucare questo sistema diventa per un hacker una sfida allettante, visto che sa
bene che spesso oltre a poter accedere alle informazioni contenute nel database può ottenere il
completo controllo dell'applicazione che lo utilizza . La sicurezza di un sito oltre a dipendere dalla
configurazione del web server dipende anche da chi sviluppa le applicazioni web. L’SQL Injection
consiste in un attacco informatico mirato a colpire le applicazioni web che si appoggiano su un
database di tipo SQL, sfruttando la cattiva pratica di molti sviluppatori nel concatenare le stringhe
destinate ad un database server inserendo codice maligno all'interno di una query. Questo tipo di
attacco consiste quindi nel manipolare dall'esterno le query nel database.
La concatenazione delle stringhe SQL viene solitamente associata a problemi di sicurezza e,
sebbene questo sia sicuramente vero, affligge anche performance e provocai errori di Runtime.
L'Sql Injection permette al malintenzionato di autenticarsi in aree protette del sito e di visualizzare
e alterare dati sensibili. Un altro punto interessante è che questo tipo di attacco non è
direttamente dipendente dalla tecnologia utilizzata, è un attacco cross-Platform, funziona per
esempio su SQL Server, MySQL, Access, Oracle, FireBird, ecc... Naturalmente l'hacker in alcuni casi
dovrà iniettare codice differente a seconda del database usato, ma nessuno è immune a priori. Le
soluzioni definitive esistono ma purtroppo molti sviluppatori sottovalutano la portata di questa
vulnerabilità.
L'unica possibilità di protezione è un controllo sui dati ricevuti da parte del programmatore,
durante lo sviluppo del programma.
Bisogna cioè assicurarsi che l'input ricevuto rispetti le regole necessarie, e questo può essere fatto
in diversi modi:
Controllare il tipo dei dati ricevuti;
Forzare il tipo dei dati ricevuti (se ad esempio ci si aspetta un valore numerico, si può forzare
l'input affinché diventi comunque un valore numerico);
Filtrare i dati ricevuti attraverso le espressioni regolari;
Sostituire i caratteri pericolosi con equivalenti caratteri innocui;
Effettuare l’Escape dei dati ricevuti.
Ovviamente, questi metodi possono essere applicati anche insieme sullo stesso dato in input.
Sicurezza informatica grazie alla matematica
Algoritmi di hash…
Ma vediamo allora la definizione precisa di funzione hash: “La funzione hash è una funzione non
iniettiva che mappa una stringa di lunghezza arbitraria in una stringa di lunghezza predefinita.”
La funziona Hash è l’irreversibile. La funzione non permette infatti di risalire al testo che ha
generato l’hash, ed è qui che molti confondono un digest con un testo cifrato. La crittografia,
come vedremo, è uno dei principali campi di applicazione delle funzioni hash, ma c’è
un’importante distinzione da fare: mentre gli algoritmi di cifratura permettono anche il processo
inverso (decifrazione), i digest sono unidirezionali, non permettono cioè di risalire al testo che lo
ha generato.
Come vengono memorizzate le password degli account dei siti web?
Penso che questa sia una domanda che più o meno ci siamo posti tutti: “come può questo tal sito
proteggere efficacemente la mia password, e quindi il mio account da intrusioni? “
Normalmente le password vengono memorizzate in un database, il quale viene tenuto il più
“lontano” possibile dalla rete (e quindi anche da potenziali hacker). Al suo interno troviamo varie
entità ed una di queste contiene le informazioni che riguardano gli account. Per fare un semplice
esempio, consideriamo solo un elenco di coppie username – password.
Username
Foo
Bar
Password
mypassword
mymoresecurepassword
Se le password fossero davvero memorizzate in questo modo, e per un qualunque motivo, un
hacker venisse in possesso del database o trovasse un bug per accedervi, avrebbe tranquillamente
accesso a tutte le password di tutti gli utenti.
Per ovviare a questo problema si ricorre allora agli hash: non vengono memorizzate direttamente
le password in chiaro, ma piuttosto i loro hash.
Username
Foo
Bar
Password
91dfd9ddb4198affc5c194cd8ce6d338fde470e2
5fba5460285313c7c0c46875d1f23b2201d153a6
Ma allora come fa il sito a riconoscere che l’utente in fase di login ha inserito la password
corretta? La risposta continua ad essere l’hash: il sito web non confronta direttamente la
password che noi inseriamo, ma piuttosto confronta se l’hash memorizzato corrisponde con l’hash
della password inserita. Quindi se gli hash corrispondono, corrisponderanno anche le password, e
l’accesso viene garantito.
Perché complicare tutto il processo? Perché così anche se l’hacker riuscisse ad ottenere l’accesso
al database, vedrebbe solo ed esclusivamente hash, che non gli permetterebbero di risalire alle
password originarie.
Insomma, vengono presi tutta una serie di accorgimenti affinché il lavoro dell’hacker venga reso
il più difficile possibile.