SQL Injection, la piaga continua...
A differenza di altre tipologie di attacchi alle applicazioni il SQL Injection purtroppo è in costante e perenne crescita sia in termini di siti compromessi sia in nuove tecniche sempre più evolute.
Non a caso il buon Raffaele tempo fa scrisse un articolo su MSDN dal titolo : Una piaga chiamata SQL Injection.
Questo attacco alle applicazioni è particolarmente insidioso perchè da un lato può essere facilmente attuato da molti (almeno nelle sue forme più semplici, come ad esempio l'inserimento di statement SQL formattati nei campi di input delle applicazioni) dall'altro può causare parecchi danni ad interi sistemi. Più volte negli anni mi è capitato di iniziare a parlare di SQL Injection presso clienti e poco dopo (tipicamente dopo la primissima demo) di interrompere la riunione perchè i responsabili applicativi scioccati dall'estrema facilità con cui si può iniziare ad attaccare volevano verificare subito le loro applicazioni in produzione... e in alcuni casi ho visto letteralmente "spegnere" in fretta e furia interi siti perchè le protezioni di sicurezza venivano bypassate senza nessun problema. Spesso manco la riunione riuscivo a terminare :-)
Gli attacchi di tipo SQL Injection possono avvenire quando una applicazione usa l'input dell’utente per costruire delle dichiarazioni dinamiche di TSQL per accedere alla base dati indipendentemente dal linguaggio e dal database utilizzato. Una delle prime “leggende” da sfatare è che l’uso di Store Procedure possa vanificare questo attacco. Nulla di più falso!!! Dipende cosa si passa alle Store Procedure… se passiamo delle stringhe che contengono l'input non preventivamente verificato o, peggio ancora, la store procedure accetta una stringa e la esegue as-is come ad esempio:
exec(@stringa),
eccoci nuovamente nei guai !!!
Questi attacchi permettono ad eventuali hackers di eseguire comandi non controllati e in alcuni casi di compromettere i sistemi che ospitano le applicazioni. Il problema infatti si aggrava nel caso in cui la connessione verso il database avvenga con credenziali di amminstratore o comunque di tipo privilegiato.
Per contrastare questo fenomeno si possono adottare alcune semplici regole:
· Verificare l’input degli utenti tramite le Regular Expressions.
· Ricordarsi che i controlli formali lato client sono utili solo per motivi di performance (per evitare inutili round-trip) e non di sicurezza. I “veri” controlli di sicurezza dei dati di input avvengono sempre server-side!
· Utilizzare Store Procedure (correttamente) e query parametrizzate.
· Eseguire il codice SQL mediante un account con privilegi minimi, in modo tale da ridurre la possibilità di eventuali danni in caso i controlli dei dati di input falliscano (secondo le buone norme del Defense in Depth).
· Non esporre gli errori SQL generati dal database all'utente finale nel caso in cui si verifichi una eccezioe nel codice. In questo modo si evita di esporre dettagli non necessari che potrebbero invece risultare utili agli autori degli attacchi. (Database Probing).
In questi giorni Microsoft ha rilasciato due tool che possono dare una mano nell’affrontare la problematica (maggiori info nell’advisory): URLSCAN 3.0 BETA e il Microsoft Source Code Analyzer for SQL Injection (MSCASI) e relativo forum . Inoltre segnalo il tool Scrawlr sviluppato da HP e Microsoft.
IMPORTANTE : Questi tool però devono essere utilizzati ed automatizzati all’interno di un continuo processo di analisi di sicurezza dei propri siti/applicazioni perché solo in questo modo è possibile garantire un livello sicurezza accettabile nel tempo!
Infine, all’interno del nostro percorso formativo sulla sicurezza applicativa potete trovare del materiale per approfondire l’argomento SQL Injection.
--Mario