L'iniezione SQL è sempre un argomento scottante, in particolare quando si tratta di sicurezza web. A questo proposito sono interessato a quali sono i passaggi che dovrebbero essere sempre presi per prevenire l'iniezione SQL all'interno di qualsiasi applicazione web? Inoltre, oltre a questi normali passaggi, c'è qualcos'altro che le persone fanno oltre la normale per impedirlo?
Sono già ottime risposte a questa domanda, tuttavia vorrei menzionarne altre:
Questo è solo per prevention e non ho preso hardl server hardening in considerazione. Vi sono tuttavia molte somiglianze.
Ulteriori difese nel caso in cui siate già vulnerabili all'iniezione sarebbe:
La difesa chiave consiste nell'utilizzare solo le API che evitano in modo sicuro le interrogazioni del database - queste sono generalmente definite istruzioni parametrizzate o preparate. Questi non possono essere utilizzati in tutti i casi (ad esempio, dove un identificatore SQL come il nome della tabella o della colonna viene fornito in fase di esecuzione), ma è l'approccio migliore laddove possibile (la maggior parte dei casi).
Nota: questo può portare a dati dannosi inseriti nel database, quindi tieni presente che quando usi questi dati altrove nell'applicazione
La seconda difesa è prendere un approccio di fuga. Questo è l'approccio "sostituire una virgoletta con due virgolette". Se devi procedere in questo modo, devi sfuggire a ogni personaggio potenzialmente dannoso , che in alcuni casi significa più di virgolette singole. Suggerirei di usare una libreria di livello superiore come OWASP ESAPI se possibile per farlo, o leggere attentamente il foglio dell'iniezione di OWASP SQL (di cui sopra).
Il passaggio principale per proteggere l'applicazione Web dall'iniezione SQL è quello di disinfettare correttamente qualsiasi input utente (in particolare l'input utilizzato nelle query SQL). In alcuni linguaggi / framework, esistono metodi standard per gestire questi valori, ad esempio utilizzando query parametrizzate invece di comporre la query unendo i valori stringa.
Dal lato dello sviluppatore del web, l'attenzione dovrebbe essere rivolta a ciò che Weber ha già menzionato.
Inoltre, potrebbe essere impostato il firewall del database, come GreenSQL: link . Funziona come un proxy tra l'applicazione e l'input dell'utente, guarda ciò che deve essere passato e così via. Tuttavia, ciò comporta un aumento del tempo di risposta.
Sto insegnando la sicurezza IT nei politecnici. Spesso per gli studenti hanno una certa confusione sui termini usati per l'iniezione SQL, quindi permettimi di provare a chiarire.
Nel contesto di un'applicazione web come Facebook,
L'iniezione SQL avviene quando il normale utente Web inserisce il codice SQL nei campi dati Ad esempio,
' OR '1'='1 into the textboxes of a login form.
La persona migliore per prevenire l'SQL injection è lo sviluppatore web, ovvero la persona incaricata di scrivere il codice per l'applicazione Web per leggere / scrivere i dati nel database.
Il modo più semplice per prevenire l'SQL injection dallo sviluppatore web è utilizzare query parametrizzate.
Le istruzioni preparate e le query con parametri indicano la stessa cosa.
Userò query parametrizzate da questo punto in poi.
Le query parametrizzate si riferiscono al modo in cui vengono definiti per la prima volta il codice SQL e quindi i dati vengono inseriti all'interno dei parametri appropriati.
Ad esempio in .Net
Update 'users' set 'name' = @name where 'id' = @id
i parametri @name e @id sono i dati. Il resto è il codice SQL.
Ricorda che le query con parametri sono di solito, ma non sempre fatte nel codice dell'applicazione web.
Ci sono 2 modi comuni per scrivere query parametrizzate.
Quindi in un certo senso, sì, le stored procedure sono una forma di query parametrizzate.
Esistono altri modi per prevenire l'iniezione SQL, evitando caratteri speciali come le virgolette singole. Ad esempio, in PHP, puoi usare mysql_real_escape_string che in pratica mette solo le barre prima delle virgolette singole.
Questo non è l'ideale a causa di problemi con% e underscore per operatore LIKE in determinati database come MySQL. vedi questo pdf per maggiori dettagli.
Per farla breve, tutte le opzioni suggerite hanno a che fare con la disinfezione (pulizia) dell'input dell'utente per eliminare il codice SQL.
Il modo migliore è utilizzare query parametrizzate a seconda del linguaggio di programmazione utilizzato.
Fine della storia.
Utilizza API decenti per l'accesso ai dati che rendano facile fare la cosa giusta, in sicurezza.
Ecco ActiveRecord v3:
# basic usage
@user = User.where(:username => '[email protected]').first
# with a SQL-string fragment, but using parameters
@projects = @user.projects.where('status = ?', params[:status])
Leggi altre domande sui tag sql-injection appsec countermeasure