Evitare l'iniezione di SQL senza parametri

Stiamo avendo un'altra discussione qui al lavoro sull'utilizzo di query sql parametrizzate nel nostro codice. Abbiamo due lati nella discussione: io e alcuni altri che dicono che dovremmo sempre usare i parametri per proteggerci dalle iniezioni sql e gli altri ragazzi che non pensano che sia necessario. Vogliono invece sostituire singoli apostrofi con due apostrofi in tutte le stringhe per evitare iniezioni sql. I nostri database eseguono tutti Sql Server 2005 o 2008 e la nostra base di codice gira su .NET framework 2.0.

Lascia che ti faccia un semplice esempio in C #:

Voglio che usiamo questo:

string sql = "SELECT * FROM Users WHERE Name=@name";
SqlCommand getUser = new SqlCommand(sql, connection);
getUser.Parameters.AddWithValue("@name", userName);
//... blabla - do something here, this is safe

Mentre gli altri ragazzi vogliono farlo:

string sql = "SELECT * FROM Users WHERE Name=" + SafeDBString(name);
SqlCommand getUser = new SqlCommand(sql, connection);
//... blabla - are we safe now?

Dove la funzione SafeDBString è definita come segue:

string SafeDBString(string inputValue) 
{
    return "'" + inputValue.Replace("'", "''") + "'";
}

Ora, finché utilizziamo SafeDBString su tutti i valori di stringa nelle nostre query, dovremmo essere al sicuro. Destra?

Esistono due motivi per utilizzare la funzione SafeDBString. In primo luogo, è il modo in cui è stato fatto dall'età della pietra e, in secondo luogo, è più facile eseguire il debug delle istruzioni sql poiché si vede la query esatta eseguita sul database.

Allora. La mia domanda è se sia davvero sufficiente utilizzare la funzione SafeDBString per evitare attacchi di sql injection. Ho cercato di trovare esempi di codice che infrangono questa misura di sicurezza, ma non riesco a trovarne alcun esempio.

C'è qualcuno là fuori che può rompere questo? Come lo faresti?

EDIT: per riassumere le risposte finora:

• Nessuno ha ancora trovato un modo per aggirare SafeDBString su Sql Server 2005 o 2008. Va bene, credo?
• Diverse risposte hanno sottolineato che si ottiene un miglioramento delle prestazioni quando si utilizzano query parametrizzate. Il motivo è che i piani di query possono essere riutilizzati.
• Siamo anche d'accordo sul fatto che l'utilizzo di query parametrizzate fornisca un codice più leggibile e più facile da mantenere
• Inoltre è più facile utilizzare sempre i parametri che utilizzare varie versioni di SafeDBString, conversioni da stringa a numero e conversioni da stringa a data.
• Utilizzando i parametri si ottiene la conversione automatica del tipo, cosa particolarmente utile quando si lavora con date o numeri decimali.
• E infine: non cercare di proteggerti da solo come ha scritto JulianR. I fornitori di database dedicano molto tempo e denaro alla sicurezza. Non c'è modo in cui possiamo fare di meglio e non c'è motivo per cui dovremmo provare a fare il loro lavoro.

Quindi, anche se nessuno è stato in grado di violare la semplice sicurezza della funzione SafeDBString, ho ricevuto molti altri buoni argomenti. Grazie!

Penso che la risposta corretta sia:

Non cercare di fare la sicurezza da solo . Usa qualsiasi libreria affidabile e standard del settore disponibile per ciò che stai cercando di fare, piuttosto che provare a farlo da solo. Qualunque sia la tua ipotesi sulla sicurezza, potrebbe non essere corretta. Per quanto sicuro possa sembrare il tuo approccio (e nella migliore delle ipotesi sembra traballante), c'è il rischio che tu stia trascurando qualcosa e vuoi davvero correre il rischio quando si tratta di sicurezza?

Usa parametri.

E poi qualcuno va e usa "invece di". I parametri sono, IMO, l'unico modo sicuro per procedere.

Inoltre evita molti problemi i18n con date / numeri; che data è il 01/02/03? Quanto fa 123.456? I vostri server (app-server e db-server) sono d'accordo tra loro?

Se il fattore di rischio non è convincente per loro, che ne dici delle prestazioni? L'RDBMS può riutilizzare il piano di query se si utilizzano parametri, migliorando le prestazioni. Non può farlo solo con la stringa.

L'argomento è una vittoria. Se riesci a trovare una vulnerabilità, i tuoi colleghi cambieranno semplicemente la funzione SafeDBString per tenerne conto e poi ti chiederanno di dimostrare che non è sicuro di nuovo.

Dato che le query parametrizzate sono una best practice di programmazione indiscussa, l'onere della prova dovrebbe essere su di loro per dichiarare perché non stanno utilizzando un metodo che è sia più sicuro che più performante.

Se il problema sta riscrivendo tutto il codice legacy, il facile compromesso sarebbe usare query parametrizzate in tutto il nuovo codice e refactoring del vecchio codice per usarle quando si lavora su quel codice.

La mia ipotesi è che il vero problema sia l'orgoglio e la testardaggine, e non c'è molto altro che puoi fare al riguardo.

Prima di tutto, il tuo campione per la versione "Sostituisci" è sbagliato. Devi mettere apostrofi intorno al testo:

string sql = "SELECT * FROM Users WHERE Name='" + SafeDBString(name) & "'";
SqlCommand getUser = new SqlCommand(sql, connection);

Quindi questa è un'altra cosa che i parametri fanno per te: non devi preoccuparti se un valore deve essere racchiuso o meno tra virgolette. Ovviamente, potresti incorporarlo nella funzione, ma poi devi aggiungere molta complessità alla funzione: come conoscere la differenza tra 'NULL' come null e 'NULL' come solo una stringa, o tra un numero e una stringa che contiene solo molte cifre. È solo un'altra fonte di bug.

Un'altra cosa sono le prestazioni: i piani di query parametrizzati vengono spesso memorizzati nella cache meglio dei piani concatenati, quindi forse il server risparmia un passaggio durante l'esecuzione della query.

Inoltre, l' escape delle virgolette singole non è sufficiente. Molti prodotti DB consentono metodi alternativi per l'escape dei caratteri di cui un utente malintenzionato potrebbe trarre vantaggio. In MySQL, ad esempio, puoi anche eseguire l'escape di una singola virgoletta con una barra rovesciata. E così il seguente valore di "nome" farebbe saltare in aria MySQL solo con la SafeDBString()funzione, perché quando raddoppi le virgolette singole il primo è ancora preceduto dalla barra rovesciata, lasciando il secondo "attivo":

x \ 'OPPURE 1 = 1; -

Inoltre, JulianR fa emergere un buon punto di seguito: NON provare MAI a fare il lavoro di sicurezza da solo. È così facile sbagliare la programmazione della sicurezza in modi sottili che sembrano funzionare, anche con test approfonditi. Poi il tempo passa e un anno dopo scopri che il tuo sistema è stato violato sei mesi fa e non l'hai mai saputo fino a quel momento.

Affidati sempre il più possibile alle librerie di sicurezza fornite per la tua piattaforma. Saranno scritti da persone che si occupano di codice di sicurezza per vivere, testati molto meglio di quello che puoi gestire e serviti dal fornitore se viene rilevata una vulnerabilità.

Quindi direi:

1) Perché stai cercando di reimplementare qualcosa che è integrato? è lì, immediatamente disponibile, facile da usare e già sottoposto a debug su scala globale. Se vengono rilevati bug futuri, verranno risolti e disponibili a tutti molto rapidamente senza che tu debba fare nulla.

2) Quali processi sono in atto per garantire di non perdere mai una chiamata a SafeDBString? Mancarlo in un solo posto potrebbe aprire tutta una serie di problemi. Quanto hai intenzione di osservare queste cose e considerare quanto è sprecato quello sforzo quando la risposta corretta accettata è così facile da raggiungere.

3) Quanto sei certo di aver coperto ogni vettore di attacco che Microsoft (l'autore del DB e della libreria di accesso) conosce nella tua implementazione di SafeDBString ...

4) Quanto è facile leggere la struttura dello sql? L'esempio usa + concatenazione, i parametri sono molto simili a string.Format, che è più leggibile.

Inoltre, ci sono 2 modi per capire cosa è stato effettivamente eseguito: lancia la tua funzione LogCommand, una semplice funzione senza problemi di sicurezza , o persino guarda una traccia sql per capire cosa pensa il database stia realmente accadendo.

La nostra funzione LogCommand è semplicemente:

    string LogCommand(SqlCommand cmd)
    {
        StringBuilder sb = new StringBuilder();
        sb.AppendLine(cmd.CommandText);
        foreach (SqlParameter param in cmd.Parameters)
        {
            sb.Append(param.ToString());
            sb.Append(" = \"");
            sb.Append(param.Value.ToString());
            sb.AppendLine("\"");
        }
        return sb.ToString();
    }

Giusto o sbagliato, ci fornisce le informazioni di cui abbiamo bisogno senza problemi di sicurezza.

Con le query parametrizzate ottieni più della protezione contro l'iniezione sql. Si ottiene anche un migliore potenziale di memorizzazione nella cache del piano di esecuzione. Se si utilizza il profiler di query del server sql, è comunque possibile vedere lo "sql esatto eseguito sul database", quindi non si perde davvero nulla in termini di debug delle istruzioni sql.

Ho utilizzato entrambi gli approcci per evitare attacchi di SQL injection e preferisco decisamente le query parametrizzate. Quando ho usato query concatenate ho usato una funzione di libreria per sfuggire alle variabili (come mysql_real_escape_string) e non sarei sicuro di aver coperto tutto in un'implementazione proprietaria (come sembra che lo sia anche tu).

Non è possibile eseguire facilmente alcun controllo del tipo sull'input dell'utente senza utilizzare i parametri.

Se utilizzi le classi SQLCommand e SQLParameter per effettuare chiamate DB, puoi comunque vedere la query SQL in esecuzione. Guarda la proprietà CommandText di SQLCommand.

Sono sempre un po 'sospettoso dell'approccio personalizzato per prevenire l'iniezione di SQL quando le query parametrizzate sono così facili da usare. Secondo, solo perché "è sempre stato fatto in quel modo" non significa che sia il modo giusto per farlo.

Questo è sicuro solo se hai la certezza di passare una stringa.

E se a un certo punto non passassi una stringa? E se passi solo un numero?

http://www.mywebsite.com/profile/?id=7;DROP DATABASE DB

Alla fine diventerebbe:

SELECT * FROM DB WHERE Id = 7;DROP DATABASE DB

Userei stored procedure o funzioni per tutto, quindi la domanda non si pone.

Dove devo mettere SQL nel codice, uso i parametri, che è l'unica cosa che ha senso. Ricorda ai dissenzienti che ci sono hacker più intelligenti di loro e con maggiori incentivi a violare il codice che sta cercando di sconfiggerli. Usare i parametri, semplicemente non è possibile e non è difficile.

D'accordo enormemente sulle questioni di sicurezza.
Un altro motivo per utilizzare i parametri è l'efficienza.

I database compileranno sempre la query e la memorizzeranno nella cache, quindi riutilizzeranno la query memorizzata nella cache (che è ovviamente più veloce per le richieste successive). Se si utilizzano parametri, anche se si utilizzano parametri diversi, il database riutilizzerà la query memorizzata nella cache poiché corrisponde in base alla stringa SQL prima di associare i parametri.

Se tuttavia non si legano i parametri, la stringa SQL cambia a ogni richiesta (che ha parametri diversi) e non corrisponderà mai a ciò che è nella cache.

Per i motivi già indicati, i parametri sono un'ottima idea. Ma odiamo usarli perché creare il parametro e assegnare il suo nome a una variabile per un uso successivo in una query è un triplice problema di indirizzamento.

La classe seguente avvolge lo stringbuilder che userete comunemente per la creazione di richieste SQL. Ti consente di scrivere query paramaterizzate senza dover creare un parametro , in modo da poterti concentrare sull'SQL. Il tuo codice sarà simile a questo ...

var bldr = new SqlBuilder( myCommand );
bldr.Append("SELECT * FROM CUSTOMERS WHERE ID = ").Value(myId, SqlDbType.Int);
//or
bldr.Append("SELECT * FROM CUSTOMERS WHERE NAME LIKE ").FuzzyValue(myName, SqlDbType.NVarChar);
myCommand.CommandText = bldr.ToString();

La leggibilità del codice, spero tu sia d'accordo, è notevolmente migliorata e l'output è una query parametrizzata adeguata.

La classe ha questo aspetto ...

using System;
using System.Collections.Generic;
using System.Text;
using System.Data;
using System.Data.SqlClient;

namespace myNamespace
{
    /// <summary>
    /// Pour le confort et le bonheur, cette classe remplace StringBuilder pour la construction
    /// des requêtes SQL, avec l'avantage qu'elle gère la création des paramètres via la méthode
    /// Value().
    /// </summary>
    public class SqlBuilder
    {
        private StringBuilder _rq;
        private SqlCommand _cmd;
        private int _seq;
        public SqlBuilder(SqlCommand cmd)
        {
            _rq = new StringBuilder();
            _cmd = cmd;
            _seq = 0;
        }
        //Les autres surcharges de StringBuilder peuvent être implémenté ici de la même façon, au besoin.
        public SqlBuilder Append(String str)
        {
            _rq.Append(str);
            return this;
        }
        /// <summary>
        /// Ajoute une valeur runtime à la requête, via un paramètre.
        /// </summary>
        /// <param name="value">La valeur à renseigner dans la requête</param>
        /// <param name="type">Le DBType à utiliser pour la création du paramètre. Se référer au type de la colonne cible.</param>
        public SqlBuilder Value(Object value, SqlDbType type)
        {
            //get param name
            string paramName = "@SqlBuilderParam" + _seq++;
            //append condition to query
            _rq.Append(paramName);
            _cmd.Parameters.Add(paramName, type).Value = value;
            return this;
        }
        public SqlBuilder FuzzyValue(Object value, SqlDbType type)
        {
            //get param name
            string paramName = "@SqlBuilderParam" + _seq++;
            //append condition to query
            _rq.Append("'%' + " + paramName + " + '%'");
            _cmd.Parameters.Add(paramName, type).Value = value;
            return this; 
        }

        public override string ToString()
        {
            return _rq.ToString();
        }
    }
}

Dal brevissimo tempo che ho avuto per indagare sui problemi di SQL injection, posso vedere che rendere un valore 'sicuro' significa anche che stai chiudendo la porta a situazioni in cui potresti effettivamente volere apostrofi nei tuoi dati - che dire del nome di qualcuno , ad esempio O'Reilly.

Ciò lascia parametri e stored procedure.

E sì, dovresti sempre cercare di implementare il codice nel modo migliore che conosci ora, non solo come è sempre stato fatto.

Ecco un paio di articoli che potresti trovare utili per convincere i tuoi colleghi.

http://www.sommarskog.se/dynamic_sql.html

http://unixwiz.net/techtips/sql-injection.html

Personalmente preferisco non permettere mai a nessun codice dinamico di toccare il mio database, richiedendo che tutti i contatti siano tramite sps (e non uno che utilizzi SQl dinamico). Ciò significa che non si può fare nulla al di fuori di ciò che ho concesso agli utenti di fare e che gli utenti interni (tranne i pochissimi con accesso di produzione per scopi di amministratore) non possono accedere direttamente alle mie tabelle e creare scompiglio, rubare dati o commettere frodi. Se esegui un'applicazione finanziaria, questo è il modo più sicuro.

Può essere rotto, tuttavia i mezzi dipendono dalle versioni / patch esatte ecc.

Uno che è già stato sollevato è il bug di overflow / troncamento che può essere sfruttato.

Un altro mezzo futuro sarebbe trovare bug simili ad altri database - ad esempio lo stack MySQL / PHP ha subito un problema di escape perché alcune sequenze UTF8 potrebbero essere utilizzate per manipolare la funzione di sostituzione - la funzione di sostituzione verrebbe indotta a introdurre i caratteri di iniezione.

Alla fine della giornata, il meccanismo di sicurezza sostitutivo si basa su previsto ma non previsto . Poiché la funzionalità non era lo scopo previsto del codice, è molto probabile che qualche stranezza scoperta interrompa la funzionalità prevista.

Se si dispone di molto codice legacy, il metodo di sostituzione potrebbe essere utilizzato come ripiego per evitare lunghe riscritture e test. Se stai scrivendo un nuovo codice, non ci sono scuse.

Utilizzare sempre query parametrizzate ove possibile. A volte anche un semplice input senza l'uso di caratteri strani può già creare un'iniezione SQL se non viene identificato come input per un campo nel database.

Quindi lascia che il database faccia il suo lavoro di identificazione dell'input stesso, per non parlare del fatto che risparmia anche un sacco di problemi quando è necessario inserire effettivamente caratteri strani che altrimenti sarebbero sfuggiti o modificati. Può anche risparmiare un po 'di tempo prezioso alla fine per non dover calcolare l'input.

Non ho visto altre risposte affrontare questo lato del "perché farlo da soli è male", ma considera un attacco di troncamento SQL .

C'è anche la funzione QUOTENAMET-SQL che può essere utile se non riesci a convincerli a usare params. Cattura molte (tutte?) Delle preoccupazioni di qoute sfuggite.

2 anni dopo , ho recidivato ... Chiunque trovi i parametri un dolore è il benvenuto a provare la mia estensione VS, QueryFirst . Modifica la tua richiesta in un vero file .sql (Validation, Intellisense). Per aggiungere un parametro, è sufficiente digitarlo direttamente nel tuo SQL, iniziando con la "@". Quando salvi il file, QueryFirst genererà classi wrapper per consentirti di eseguire la query e accedere ai risultati. Cercherà il tipo di DB del tuo parametro e lo mapperà a un tipo .net, che troverai come input per i metodi Execute () generati.Non potrebbe essere più semplice. Farlo nel modo giusto è radicalmente più veloce e più facile che farlo in qualsiasi altro modo, e creare una vulnerabilità di sql injection diventa impossibile, o almeno perversamente difficile. Ci sono altri vantaggi killer, come la possibilità di eliminare colonne nel tuo DB e vedere immediatamente gli errori di compilazione nella tua applicazione.

disclaimer legale: ho scritto QueryFirst

Ecco alcuni motivi per utilizzare le query con parametri:

1. Sicurezza: il livello di accesso al database sa come rimuovere o sfuggire agli elementi non consentiti nei dati.
2. Separazione delle preoccupazioni: il mio codice non è responsabile della trasformazione dei dati in un formato che piace al database.
3. Nessuna ridondanza: non è necessario includere un assembly o una classe in ogni progetto che esegue la formattazione / escape del database; è integrato nella libreria di classi.

C'erano poche vulnerabilità (non ricordo quale database fosse) che è correlata al buffer overflow dell'istruzione SQL.

Quello che voglio dire è che SQL-Injection è più che semplicemente "sfuggire alla citazione", e non hai idea di cosa verrà dopo.

Un'altra considerazione importante è tenere traccia dei dati con escape e senza escape. Ci sono tonnellate e tonnellate di applicazioni, Web e non, che non sembrano tenere traccia correttamente di quando i dati sono raw-Unicode, & -encoded, HTML formattato, eccetera. È ovvio che diventerà difficile tenere traccia di quali stringhe sono ''codificate e quali no.

È anche un problema quando si finisce per cambiare il tipo di una variabile - forse era un numero intero, ma ora è una stringa. Adesso hai un problema.