Che cosa rende vulnerabile un'applicazione Android a SQL Injection?

Gli attacchi di SQL injection si applicano quando un'applicazione usa SQL e assembla incautamente richieste SQL con elementi forniti da un utente malintenzionato. Qui, "incautamente" significa "senza utilizzare istruzioni preparate ". Le istruzioni preparate sono il modo corretto di fare SQL con dati forniti esternamente; molti sviluppatori tentano di pensarlo in termini di "escape dei caratteri di quotatura", che è un metodo sbagliato e porta a un disastro (anche se alla fine qualcosa sfugge, solo le dichiarazioni preparate garantiscono che sia fatto correttamente).

Android non è un fattore in tutto questo, tranne in modo molto indiretto: Android viene fornito con SQLite , quindi gli sviluppatori sono molto tentati di usarlo e quindi giocare con SQL, anche nei casi in cui non è strettamente necessario. Quando il tuo unico strumento è un martello, è meglio che i problemi siano i chiodi, perché ci sarà un duro colpo. Naturalmente, quando gli sviluppatori hanno il potere di SQL ma non sono abbastanza attenti a usarlo correttamente, allora gli attacchi di SQL injection diventano una possibilità definita.

Un altro effetto è che le applicazioni Android si basano su un linguaggio simile a Java, che è intrinsecamente protetto dagli overflow del buffer (perché tutti gli accessi agli array sono controllati sistematicamente) e dalle situazioni double-free e use-after-free (a causa del GC gestione della memoria basata su). Pertanto, altri tipi di attacchi costituiscono meccanicamente una percentuale maggiore di tutte le vulnerabilità complessive. Avere molte vulnerabilità di SQL injection nelle app Android potrebbe essere, in effetti, il risultato di avere relativamente meno di altri tipi di attacchi.

SQLite supporta query preparate e parametri associati, quindi il problema è più legato all'uso dello strumento piuttosto che allo strumento stesso.

Se si utilizzano parametri di interrogazione è impossibile iniettare SQL nel processo perché i dati vengono gestiti separatamente dall'istruzione. Il problema sorge solo se lo sviluppatore ha fatto qualcosa del tipo:

SQLStatement="seleziona * dagli utenti dove password = '" + thePassword + "' e email = '" + theEmailAddr + "';";

Questo perché offre all'utente la possibilità di digitare una password che termina l'istruzione e ne aggiunge un'altra, oppure specificare le condizioni in cui qualsiasi password potrebbe funzionare. Ad esempio, se l'utente digita una password di

' or password!='fred

e un indirizzo email reale, ad esempio [email protected], la query inviata al database è:

select * from users where password='' or password!='fred' and email='[email protected]';

Se si utilizzano i parametri, non è possibile inserire nuovi sql nel testo del comando, poiché i dati vengono trattati separatamente dal comando.