Leggerai questo articolo in: 4 minuti

Oggi come promesso inizierò a parlarti di ogni tipo di attacco presente nella OWASP Top 10. In particolare in questo articolo verrà trattata la vulnerabilità A1-Injection.

Le Injection Flaws, come SQL Injection, OS Injection, e LDAP injection, si verificano quando dei dati non validati vengono inviati come parte di un comando o di una query direttamente al loro interprete. Il dato infetto può quindi ingannare tale interprete, eseguendo comandi non previsti o accedendo a dati per i quali non si ha l’autorizzazione.

Sicurezza web owasp top 10 – Analisi e contromisure per A1 – Injection

Agenti di minaccia: Qualsiasi persona in grado di mandare dati non controllati al sistema, inclusi utenti interni ed esterni o amministratori. Vale sempre il detto “All input is evil until proven otherwise”.
Vettori di attacco: In modo più o meno semplice l’attaccante invia un semplice testo che usa la sintassi dell’interprete obiettivo dell’attacco.
Problematiche di Sicurezza: Gli Injection flaws avvengono quando un’applicazione invia dati non controllati (validati) ad un interprete. Questo tipo di debolezza si trova molto spesso nelle query SQL, LDAP, XPath, comandi OS, ecc. Questo tipo di vulnerabilità può essere facilmente individuata esaminando direttamente il codice, mentre il tutto risulta più difficile e di non sicura garanzia un analisi tramite il testing. L’ideale sarebbe sempre usare tutti e due gli approcci.
Impatti Tecnici: Un Injection può portare ad una perdita o alla parziale/totale corruzione dei dati, mancanza di tracciabilità o rifiuto di accesso ad esempio in sistemi che richiedono un login. In alcuni casi può portare alla totale presa di controllo del sistema.
Impatti di Business: Considerare il valore di business dei dati impattati e della piattaforma su cui gira l’interprete. Tutti i dati potrebbero essere rubati, modificati o cancellati. E’ quindi importante prendere atto che i dati sui quali lavora la nostra applicazione potrebbero essere sensibili e come tali debbano essere protetti.

Sono vulnerabile?
Il modo migliore per verificare se la nostra applicazione è vulnerabile all’ “injection” è quello di verificare che tutti gli interpreti di comandi dell’applicazione separino chiaramente i dati di input dai comandi e dalle query. Ad esempio per le chiamate SQL, questo comporterà l’uso di variabili bind in tutte le istruzioni e stored procedure, evitando query di tipo dinamico.

Il controllo del codice da un occhio esperto è un modo veloce ed accurato per verificare se un applicazione utilizza i moduli in maniera sicura. Gli strumenti di analisi del codice possono aiutare gli analisti di sicurezza nel verificare l’uso dei moduli e tracciare il comportamento dell’applicazione.

Attraverso tool adatti al penetration test possiamo verificare le carenze di controlli creando exploit che confermino la vulnerabilità. Gli scanner automatici possono evidenziare l’esistenza di Injection conosciuti. Gli scanner però d’altro canto non possono raggiungere sempre tutti i moduli della nostra applicazione e potrebbero esserci problemi nel verificare se effettivamente un attacco è andato a buon fine.

Una gestione degli errori carente inoltre rende un Injection flaw scuramente più facile da scoprire da parte dell’attaccante, è sempre buona norma non mostrare a video gli errori.

Esempi di Scenario di Attacco

L’applicazione usa dati non controllati nella costruzione della seguente chiamata SQL vulnerabile:

1
 String query = "SELECT * FROM accounts WHERE custID='" + request.getParameter("id") +"'";

L’attaccante modifica il parametro ‘id’ nel browser per mandare la stringa seguente: ‘or’1’=‘1. Questo cambia il significato della query per selezionare tutti I record dal data base dei clienti, invece dei soli dati del codice cliente richiesto.

1
http://example.com/app/accountView?id=’ or ’1’  =  ’1

Nel caso peggiore, l’attaccante usa questa debolezza per chiamare stored procedure speciali nel data base, che permettono di prendere il controllo completo del database e persino del server che ospita il data base.

Come mi difendo?
Prevenire un injection richiede fondamentalmente che i dati di input siano tenuti separati da comandi e query.
1. L’opzione preferita è quella di usare API sicure che eviti l’uso di un interprete o che fornisca un’interfaccia parametrizzata.
2. Se non sono disponibili API parametrizzate, è necessario evitare caratteri speciali usando soluzioni sintattiche (escape) specifiche per quell’interprete. OWASP’s ESAPI ad esempio (per il linguaggio Java) ha alcune di queste escaping routines.
3. La validazione di input in “white list”, non basta, poichè alcune applicazioni richiedono caratteri speciali nei loro input, e in ogni caso un attaccante potrebbe usare un’altra codifica per rappresentare un determinato carattere.

Risorse Utili:
SQL Injection Prevention Cheat Sheet

Come sempre se ti è piaciuto questo articolo, hai qualche dubbio, richiesta o curiosità non esitare a lasciarmi un commento.
Nella speranza di riaverti presto qui ti auguro una splendida giornata!

Non dimenticare di condividere l’articolo su Facebook, Twitter, Google+.

 
[adsense]