L'SQL injection è sempre un tema caldo soprattutto quando si parla di sicurezza web, a tal proposito mi interessa quali sono i passaggi da compiere sempre per prevenire l'SQL injection all'interno di qualsiasi applicazione web? Inoltre, oltre a questi passaggi normali, c'è qualcos'altro che le persone fanno oltre il normale per prevenirlo?
Già risposte molto buone su questa domanda, tuttavia vorrei citarne altre:
Questo è solo per prevenzione e non ho preso hardening del server sql in considerazione. Ci sono tuttavia molte somiglianze.
Ulteriori difese nel caso in cui tu sia già vulnerabile all'iniezione potrebbero essere:
Istruzioni preparate, query parametrizzate, sfuggire a tutti gli input dell'utente, per un buon inizio vedere http://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet.
La difesa principale consiste nell'utilizzare solo API che sfuggono in modo sicuro alle query del database: queste vengono generalmente definite istruzioni parametrizzate o preparate. Questi non possono essere utilizzati in tutti i casi (ad esempio quando un identificatore SQL come il nome della tabella o della colonna viene fornito in fase di esecuzione), ma è l'approccio migliore dove possibile (la maggior parte dei casi).
Nota: questo può portare all'inserimento di dati dannosi nel database, quindi tienilo presente quando utilizzi questi dati altrove nell'applicazione
La seconda difesa è adottare un approccio di fuga . Questo è l'approccio "sostituire una virgoletta singola con due virgolette". Se devi procedere in questo modo, devi sfuggire a ogni carattere potenzialmente dannoso , il che significa più di virgolette singole in alcuni casi. Ti consiglio di utilizzare una libreria di livello superiore come OWASP ESAPI, se possibile, per farlo per te, o leggere attentamente il Cheat Sheet di OWASP SQL Injection (a cui si fa riferimento sopra).
Il passaggio principale per proteggere l'applicazione web dall'iniezione SQL è disinfettare adeguatamente qualsiasi utente input (soprattutto 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 valori stringa.
Da parte degli sviluppatori web, l'attenzione dovrebbe essere puntata su ciò che Weber ha già menzionato.
Inoltre, potrebbe essere impostato un firewall del database, come GreenSQL: http://www.greensql.net/. Funziona come un proxy tra l'applicazione e l'input dell'utente, controlla ciò che dovrebbe essere passato e così via. Tuttavia, ciò comporta un aumento del tempo di risposta.
Insegno sicurezza IT in politecnici. Spesso gli studenti hanno una certa confusione sui termini usati per SQL injection, quindi lasciatemi provare a chiarire.
Nel contesto di un'applicazione web come Facebook,
SQL injection è quando il il normale utente web inserisce il codice SQL nei campi dati Es.
'OR' 1 '=' 1 nelle caselle di testo di un modulo di accesso. per prevenire l'iniezione di SQL è lo sviluppatore web, ovvero la persona incaricata di scrivere il codice per l'applicazione web per leggere / scrivere dati nel database.
Il modo più semplice per prevenire l'iniezione di SQL da parte dello sviluppatore web è usare query con parametri.
Le istruzioni preparate e le query con parametri significano la stessa cosa.
Userò le query con parametri da questo punto in poi.
Le query parametrizzate si riferiscono al modo in cui il codice SQL viene prima definito e quindi i dati vengono inseriti nei parametri appropriati.
Ad esempio in .Net
Aggiorna `users` set` name` = @name dove `id` = @id i parametri @name e @id sono i dati. Il resto è il codice SQL.
Tieni presente che le query parametrizzate vengono solitamente ma non sempre eseguite nel codice dell'applicazione web.
Ci sono 2 comuni modi 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, ovvero l'escape di caratteri speciali come le virgolette singole. Ad esempio, in PHP, puoi usare mysql_real_escape_string che fondamentalmente mette solo le barre prima delle virgolette singole.
Questo non è l'ideale a causa di problemi con% e underscore per l'operatore LIKE in alcuni 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 ripulire il codice SQL.
Il modo migliore è utilizzare query parametrizzate a seconda del linguaggio di programmazione utilizzato.
Fine della storia.
Usa API decenti per l'accesso ai dati che rendono facile fare la cosa giusta, in sicurezza.
Ecco ActiveRecord v3:
# basic usage @ user = User. where (: username = > 'joe@example.com'). first # with a SQL-string fragment, but using parameters @ projects = @ user.projects.where ('status =?', params [: status])