29/11/2012

Sicurezza SQL (Sql Injection parte 2)    

In un articolo precedente  è stata introdotta la problematica della sicurezza di un sito internet.
Utilizzando banali esempi, abbiamo illustrato quanto sia importante curare la sicurezza di un'applicazione web; con semplici stratagemmi è facile ad esempio ottenere dal sito, l'elenco degli utenti abilitati ad accedere ad un'area riservata. 

La finalità di un attacco SQL può essere orientata a diversi scopi. Si pensi, per esempio, alla possibilità di inserire codice malevolo in una pagina web, in modo da pilotarne il comportamento. Tramite una SQL Injection si può individuare la tabella dei contenuti ed accedervi inserendo codice script; quest'ultimo sarà eseguito dall'utente che visualizzerà la  pagina così modificata.

Nel 2011 un attacco sql colpì circa settecentomila siti internet, tra cui il sito  iTunes della Apple; l'attacco prese il nome di LizaMoon.
LizaMoon sfruttò la possibilità di "inettare" codice malevolo in database tramite query mirate; il sito infettato ridirezionava gli utenti che vi si collegavano ad una pagina che li informava di una presunta vulnerabilità del proprio sistema.

Dopo averli invitati ad effettuare una scansione, proponeva l'acquisto di un software per disinfettare il computer. Il prezzo proposto era scontatissimo; l'utente non doveva fare altro che fornire le credenziali della carta di credito, ed il gioco era fatto.
LizaMoon utilizzò la tecnica di sql injection illustrata. Il codice iniettato era simile al seguente "+update+Tabella+set+nomedelcampo=£REPLACE(cast(char(60)%2Bchar(50)%2Bchar(116) as varchar(10)".....n. la query, apparentemente senza senso, consente di inserire un testo del tipo "document.location="http:\\sito di phishing\sessionid=?489648648686847408489489"

Tecniche di protezione

Appreso il modo in cui è possibile attaccare un sito, lo sviluppatore può correre ai ripari seguendo pochi, ma fondamentali accorgimenti.
Come prima regola, è buona pratica ridurre, nei limiti del possibile, i privilegi dell'utente SQL che si utilizza per la connessione al database. E', per esempio, pericoloso dare i privilegi di sysadmin o dbowner, ad un utenza che avrà come unico requisito funzionale l'accesso in sola lettura al database.
Una accurata gestione degli errori, inoltre, nasconderebbe all'utente i messaggi inviati direttamente dal DBMS.

E' inoltre di vitale importanza la corretta validazione degli input: il processo di validazione permette di filtrare i contenuti passati alle query sql. E' essenziale che ciò avvenga lato server; un controllo fatto da script, quindi lato utente, potrebbe non essere sufficiente. 
E' possibile utilizzare diverse strategie per la validazione degli input:
 - controllo del tipo dei dati inviati: il type casting consente di accertarsi che i dati passati alle query siano del tipo desiderato.
Per esempio, nel caso in cui il parametro atteso sia un intero, potremmo effettuare alcuni banali controlli prima di passare il dato alla query: grazie alle funzioni IsNumeric(), is_numeric(), gettype() (variano a seconda del linguaggio di programmazione utilizzato), sarà possibile analizzare il tipo di dato prima di inoltrarlo alla query, e gestirne il corretto comportamento.
- Controllare i dati immessi escludendo i caratteri che, sicuramente, non sono validi; per esempio, nel caso in cui l'utente debba inserire un indirizzo mail, il range di caratteri ammessi è il seguente: "0123456789 @.-_+ abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ". Per la verifica delle espressioni regolari i linguaggi di programmazione mettono a disposizione funzioni native (es. preg_match() in PHP).
- Epurare i parametri da eventuali stringhe pericolose. Appartengono a tale insieme, per esempio, le parole chiave del linguaggio SQL. Bisogna prestare massima attenzione anche all'introduzione di apici e caratteri di escape. In PHP, per esempio, troviamo la funzione "get_magic_quotes()" che epura i parametri dai caratteri pericolosi.

Ciò non sempre è possibile. In situazioni in cui si sia optato per una scelta di CMS, CMR o blog opensource, quali  WordPressJoomla,  Jahia,  Alfresco, Phpnuke, è buona norma prevedere aggiornamenti frequenti, scaricandoli dai rispettivi siti web. Capita di frequente che, scoperta una falla in un'applicazione opensource, gli hacker si lancino alla scansione di tutti i siti che li ospitano, causando disagi e spesso danni all'utenza che vi accede.

Autore:
Michele Buffolino
Michele Buffolino

Tags: Sicurezza, SQL


©2017  SNAP s.r.l. Via Cap. Luca Mazzella, 40-44 82100 Benevento

Telefono +39 0824 21080 - Fax 0824 1810300 - Partita Iva 01066160621

Contatti | Utilizzo | Privacy | Ricerca | Seguici su Facebook | | LinkedIn