Aggiornato al : mag 30, 2008

Alcuni server SQL sono soggetti a vulnerabilità strettamente legate allo stesso software con i quali sono stati progettati: è un esempio il server MySQL, con la sua funzione mysql real escape string(), che verrà descritta in dettaglio nel prossimo articolo. Tale funzione è utilizzata per generare un comando SQL valido a partire da una stringa, quale può essere quella inserita da un utente per l’interrogazione
di un database. Solo recentemente è stata rilevata una vulnerabilità che si verifica quando si ha a che fare con parametri numerici, che vengono utilizzati in assenza di apici all’interno delle query SQL. Dal momento che la funzione mysql realescape string() riesce a neutralizzare gli attacchi di SQL injection agendo proprio su caratteri speciali come gli apici, in tal caso l’attacco riesce a passare inosservato
(almeno fin quando non ne saranno visibili le conseguenze!). Questo è solo un esempio di vulnerabilitµa di un server SQL, le cui debolezze possono essere insite nella stessa implementazione del DBMS adottato. Volendo ad esempio prendere in esame il server MS-SQL, nel 2002 µe stata rilevata una grave vulnerabilitµa che consentiva all’utente di autenticarsi con privilegi di amministratore mediante un account di default con nome utente `sa’ e privo di password.
Naturalmente potrebbero essere fatti svariati altri esempi di vulnerabilità, ma quanto detto µe su±ciente per trarre tre importanti conclusioni. La prima è mai fidarsi ciecamente di un DBMS: anche se mette a disposizione strumenti atti a proteggersi da attacchi di SQL injection, l’esempio di MySQL dimostra che
non è assolutamente certo che tali strumenti siano sicuri a sufficienza. È quindi di notevole importanza adottare alcune contromisure, che verranno descritte negli articoli successivi, a prescindere dalla sicurezza offerta dal DBMS in uso.
La seconda conclusione µe mai utilizzare un DBMS senza averlo configurato opportunamente al momento della sua installazione. I famosi parametri di default spesso costituiscono falle nella sicurezza, in particolare è necessario impostare delle password adeguate.
La terza ma non meno importante conclusione è: quando si tratta di sicurezza essere paranoici è fondamentale; il livello di paranoia dev’essere direttamente proporzionale all’importanza di ciò che vogliamo tutelare!

Articolo Precedente -> Techiche di attacco mediante messaggi di errore ODBC (Sql Injection)

Articolo successivo -> Tecniche di protezione da attacchi di SQL injection

Autore : Simon. U

You may be the one to comment first. Please leave your message below.