Domanda:
Best practice per prevenire l'iniezione di SQL?
Mark Davidson
2010-12-21 01:56:34 UTC
view on stackexchange narkive permalink

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?

Sette risposte:
#1
+19
Chris Dale
2010-12-21 19:41:49 UTC
view on stackexchange narkive permalink

Già risposte molto buone su questa domanda, tuttavia vorrei citarne altre:

  • Codifica sicura (che è già stata menzionata da molti già)
    • Utente in fuga input
    • Query parametrizzate (istruzioni preparate, query predefinite in cui si legano solo variabili)
    • Codice difensivo
  • Monitoraggio degli attacchi
    • Network Intrusion Detection System (NIDS)
    • Host Intrusion Detection System (HIDS)
    • Application Intrusion Detection System (AppIDS)
  • Blocca gli attacchi
    • Firewall dell'applicazione
    • Firewall del database
    • Firewall dell'applicazione web
      • Apache ModSecurity
      • Cisco Application Velocity System (AVS)
  • Sonda per vulnerabilità
    • Test automatizzato di blackbox injection
    • Statico analisi del codice sorgente
    • Test di penetrazione manuale

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:

  • Eseguire la tua applicazione con il minor numero di concessioni necessarie
    • Concedi specificamente solo l'accesso al database e alle tabelle di cui hai bisogno
    • Assicurati di concedere solo i privilegi di cui ha bisogno (di solito seleziona, inserisci, aggiorna)
+1, risposta molto buona. Un commento, però, rispetto al tuo ultimo paragrafo: è meglio non concedere * alcun * accesso direttamente alle tabelle, ma utilizzare procedure memorizzate e concedere l'accesso solo a esse.
#2
+16
Weber
2010-12-21 02:02:13 UTC
view on stackexchange narkive permalink

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.

ottimo collegamento. Qualsiasi possibilità di far apparire i punti chiave nel corpo della tua risposta: rende più facile per qualcuno trovare i contenuti e migliora anche l'indicizzazione di queste domande e risposte da parte dei motori di ricerca.
Sono d'accordo con @Rory - puoi inserire qualche informazione in più nella risposta? Soprattutto qualche riferimento alle stored procedure - nessun altro lo ha menzionato, vedo ...
@AviD: Le stored procedure ** sono ** un tipo specifico di istruzione preparata
@symcbean - Immagino che semanticamente sia vero, ma in genere si fa riferimento a "istruzione preparata" nell'applicazione, anziché nel database.
#3
+10
Justin Clarke
2010-12-21 16:53:44 UTC
view on stackexchange narkive permalink

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).

#4
+9
bretik
2010-12-21 17:07:42 UTC
view on stackexchange narkive permalink

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.

#5
+4
anonymous
2010-12-21 02:36:59 UTC
view on stackexchange narkive permalink

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.

Fantastico: mai sentito parlare di greenSQL prima.
#6
+4
Kim Stacks
2011-01-18 22:19:28 UTC
view on stackexchange narkive permalink

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.

  1. Nel codice dell'applicazione web a seconda della lingua utilizzata
  2. Nel database utilizzando procedure memorizzate

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.

#7
+3
yfeldblum
2011-01-19 08:22:05 UTC
view on stackexchange narkive permalink

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 = > '[email protected]'). first # with a SQL-string fragment, but using parameters @ projects = @ user.projects.where ('status =?', params [: status])  


Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 2.0 con cui è distribuito.
Loading...