Owasp Capitolo 3: la categoria delle injection lascia il trono ad altre vulnerabilità, ma resta ancora tra le più pericolose
Precedentemente classificata come la regina incontrastata delle vulnerabilità troviamo la categoria delle injection. Forse da sempre una delle falle più pericolose e più facili da utilizzare.
Un applicativo è vulnerabile a questo tipo di attacco se:
- I dati immessi dagli utenti non vengono validati, filtrati e/o sanificati dall’applicativo
- Query dinamiche o chiamate non parametrizzate, senza la possibilità di eseguire escape contestuali, vengono usate direttamente nell’interpretatore
- Dati malevoli vengono usati all’interno dei parametri di ricerca delle mappature orientate agli oggetti (ORM), per estrapolare dati sensibili addizionali
- Dati malevoli vengono utilizzati direttamente o concatenati. I comandi SQL contentono la struttura e i dati malevoli nelle query dinamiche, nei comandi o nelle stored procedures
- Alcune delle tecniche di injection più popolari sono SQL, NoSQL, comandi del SO, ORM, LDAP etc…
Il concetto è sempre quello. Fare revisione del codice sorgente è il metodo migliore per rilevare se un’applicativo è vulnerabile alle injection.
Come difendersi?
Per prevenire le Injection bisogna tenere separati i dati da query e comandi:
- Usate API sicure, il che permette di bypassare completamente l’uso di un interprete, offre un’interfaccia parametrizzata o effettua una migrazione ai tool di ORM
- Utilizzate validazione dell’input positiva lato server. Non è comunque sufficiente, in quanto molte applicazioni richiedono caratteri speciali, come le aree di testo o le API per applicativi mobile
- Per ogni altra query dinamica, effettuare l’escape dei caratteri utilizzando la sintassi specifica per quell’inteprete
- Utilizzate i controlli SQL come ad esempio LIMIT per evitare una diffusione di massa di record in caso di una SQL Injection.