Iniezione SQL: perché le citazioni di escape non sono più sicure?

Why can't we escape all user input using "magic"?

Nel momento in cui viene applicata la magia, non si sa dove finiranno i dati. Quindi le virgolette stanno distruggendo dati che, a meno che non siano scritti senza caratteri di escape in un database.

Potrebbe essere usato solo nella risposta HTML inviata al client. Pensa a una forma che non è stata completamente riempita e viene quindi mostrata di nuovo all'utente. Con le virgolette magiche, i dati inseriti al primo tentativo saranno ora sottoposti a escape SQL, il che è privo di significato su una pagina HTML. Ancora peggio: al secondo invio i dati vengono nuovamente sottoposti a SQL di escape.

Why wasn't addslashes "good enough"?

Ha problemi con i caratteri multibyte:

' 27
\ 5c
뼧 bf 5c

Questi sono due byte, ma solo un carattere Unicode.

Poiché addslashes non sa nulla di Unicode, converte l'input bf 27 in bf 5c 27 . Se viene letto da un programma in grado di riconoscere Unicode, è visto come 뼧 '. Boom.

C'è una buona spiegazione di questo problema su link

Whats wrong with using DB-specific escape functions, and why was it better than addslashes?

Sono migliori perché garantiscono che l'escaping interpreti i dati nello stesso modo in cui funziona il database (vedi l'ultima domanda).

Dal punto di vista della sicurezza, sono a posto se li usi per ogni singolo input di database. Ma hanno il rischio che tu possa dimenticare entrambi da qualche parte.

Modifica : come aggiunto getahobby: O che usi xxx_escape_strings per i numeri senza aggiungere virgolette attorno a loro nell'istruzione SQL e senza assicurarti che siano numeri effettivi mediante la fusione o la conversione dell'input nell'appropriato tipo di dati / Modifica

Da un punto di vista dello sviluppo del software sono cattivi perché rendono molto più difficile aggiungere il supporto per altri software per server di database SQL.

Why are prepared statements with frameworks and PDO being hailed as the gold standard of SQL? Why are they better?

I PDO sono per lo più una buona cosa per ragioni di progettazione del software. Rende molto più semplice il supporto di altri software per server di database. Ha un'interfaccia orientata agli oggetti che astrae molte delle incompatibilità specifiche del database.

Why can't I do an SQL injection with these [prepared statements], where as I COULD have with the previously mentioned means?

La parte " query costante con parametri variabili " delle istruzioni preparate è ciò che è importante qui. Il driver del database sfuggirà automaticamente a tutti i parametri senza che lo sviluppatore debba pensarci.

Le query parametrizzate sono spesso più facili da leggere rispetto alle normali query con parametri di escape per motivi sintattici. A seconda dell'ambiente, potrebbero essere un po 'più veloci.

Utilizzare sempre istruzioni preparate con parametri è qualcosa che può essere convalidato da strumenti di analisi del codice statico . Una chiamata mancante a xxx_escape_string non viene individuata facilmente e in modo affidabile.

Can a programmer not somehow manage to still screw this up? What should they look out for?

Le "istruzioni preparate" implicano che sono costanti . Generazione dinamica di istruzioni preparate, in particolare con l'input dell'utente, hanno ancora tutti i problemi di iniezione.

[1.] Why can't we escape all user input using "magic" ?

Perché le virgolette sono rotte su due fronti:

1. Non tutti i dati $ _ (REQUEST / GET / POST) vanno nel DB. E per farti capire, devi sfuggire l'input.
2. Sono l'equivalente di addslashes (vedi la mia nota su [2.]), quindi non sono effettivamente sicuri.

[2.] Why wasn't addslashes "good enough"?

Ci sono molti modi per uscire dalla restrizione di addslashes , quindi, è fondamentalmente imperfetto, comunque tu provi ad usarlo.

[3.] Whats wrong with using DB-specific escape functions, and why was it better than addslashes?

Niente di veramente. Questo è semplicemente il mantra sul perché i PDO / preparati sono "migliori". Sono modo migliori di addslashes poiché si prendono cura di molti fattori, inclusa la codifica. Ecco un piccolo segreto; PDO li usa internamente, ma non addslashes ...

[4.] Why are prepared statements with frameworks and PDO being hailed as the gold standard of SQL? Why are they better? Why can't I do an SQL injection with these, where as I COULD have with the previously mentioned means?

Sono non lo standard d'oro , sono non "più" sicuri di funzioni specifiche di DB e tu puoi eseguire l'iniezione SQL con questi pure. E no, non puoi fare un'iniezione SQL con un input opportunamente igienizzato.

Come con tutte le tecnologie là fuori, gli sviluppatori tendono a sviluppare tendenze religiose (fanatiche?) per qualsiasi cosa "nuova". Questo è il motivo per cui consulti Zend Certified Engineers (TM), esperto, che ti obbliga a passare a istruzioni preparate.

La realtà, tuttavia, è che tutto dipende dal sapere cosa stai facendo. Se stai caricando un articolo con il suo ID numerico, non hai bisogno di alcun tipo di escape, anche meno PDO. Devi semplicemente assicurarti che l'ID sia effettivamente un numero intero.

Da una prospettiva più realistica, la regola generale non è usare istruzioni DOP / preparate, ma per usare le funzioni giuste, vale a dire, deve usare mysql_real_escape_string() invece di addslashes() o mysql_escape_string() .

[5.] Can a programmer not somehow manage to still screw this up? What should they look out for?

Certo! Ma non è "cosa cercare", ma piuttosto "sai cosa stai facendo".

Come vedi, eval($_GET['code']) * è del tutto legittimo se usato nel posto giusto (come un PHP Test Runner locale).

Se si utilizza un ORM per eseguire una query condizionale, si immette direttamente il codice, quindi potrebbe esserci una possibilità di ottenere l'iniezione SQL se non lo si fa correttamente (dipende dall'ORM in questione). (Ipotetico) Esempio:

// update() sets the value of a column given a condition
//
//                         .--escaping is automatic here
//                         |                           .--hypothetical SQL injection
//                         v                           v
Db()->update('name',$_GET['newname'])->where(' id = '.$_GET['id']);

(* Posso solo immaginare gli innumerevoli professionisti che sbattono la testa su questo)

Alla fine della giornata è necessario eseguire l'escape degli input per proteggere le query da SQL Injection. Le librerie di query parametrizzate come PDO e ADODB utilizzano l'escaping , tutto ciò che fanno è applicare questa pratica in modo implicitamente sicuro. Con constrast magic_quotes_gpc fa NON , questo è un approccio fondamentalmente errato al problema.

1) La fuga può essere problematica se non capisci cosa stai facendo. Questo tipo di problema è ancora sfruttabile se magic_quotes_gpc è abilitato.

mysql_query("select * from users where id=".addslashes($_GET[id]));

Exploit PoC: link )

mysql_query("select * from users where id='".addslashes($_GET[id])."'");

mysql_query("select * from users where name='".htmlspecialchars($_GET[name],ENT_QUOTES)."' and id='".htmlspecialchars($_GET[id],ENT_QUOTES)."'");

Exploit PoC: link \ & id = + o + sleep (30) / *

mysql_query("select * from users where name='".addslashes($_GET[name])."' and id='".addslashes($_GET[id])."'");

mysql_query("SET CHARACTER SET 'gbk'");
mysql_query("select * from user where name='".addslashes($_GET[name])."'");

mysql_query("SET CHARACTER SET 'gbk'");
mysql_query("select * from user where name='".mysql_real_escape_string($_GET[name])."'");

Informazioni sulle funzioni di escape specifiche del DB. Esistono molti scenari in cui può verificarsi l'iniezione SQL, anche se mysql_real_escape_string () è stato utilizzato. LIMIT e ORDER BY sono davvero difficili!

Questi esempi sono vulnerabili all'iniezione SQL:

$offset = isset($_GET['o']) ? $_GET['o'] : 0;
$offset = mysql_real_escape_string($offset);
$sql = "SELECT userid, username FROM sql_injection_test LIMIT $offset, 10";

o

$order = isset($_GET['o']) ? $_GET['o'] : 'userid';
$order = mysql_real_escape_string($order);
$sql = "SELECT userid, username FROM sql_injection_test ORDER BY '$order'";

In entrambi i casi non è possibile utilizzare 'per proteggere l'incapsulamento.

fonte : L'Inaspettata SQL Injection (quando la fuga non è sufficiente) < - Leggi questo

I filtri possono essere ignorati e i dati che vanno nelle istruzioni SQL possono provenire da più punti rispetto all'input dell'utente. I punti di ingresso in un source / sink influenzato da SQL possono essere memorizzati (ordine superiore), come un esempio, ma chiaramente i parametri GET HTTP ei parametri POST dai moduli HTML non sono gli unici modi di input dell'utente.

Le query parametrizzate non rendono necessariamente le tue istruzioni SQL libere da iniezioni. Richiedono inoltre il binding variabile, la rimozione delle operazioni di stringa / concatenazione e l'eliminazione di determinati problemi di sicurezza con una vasta gamma di clausole SQL.

La maggior parte degli sviluppatori dimentica anche di controllare i componenti di terze parti e altre dipendenze per problemi di iniezione SQL, e talvolta non si rende conto che queste inclusioni potrebbero rendere vulnerabile il proprio codice.

La cosa migliore da fare è assumere una società di consulenza sulla sicurezza delle applicazioni per preparare le applicazioni per la preparazione alla produzione e addestrare i tuoi team appdev sulla costruzione di controlli di sicurezza delle applicazioni nella loro tecnologia di processo e di sviluppo.

Espandere la risposta di Hendrick. È facile pensare a real_escape_string come a un proiettile magico quando in realtà non lo è. Ho visto persone che usano quella funzione quando vogliono usare intval o lanciare l'input su un intero. Puoi comunque essere iniettato se usi la stringa di escape nel contesto sbagliato.

Dato che il punto è aiutarti a imparare come scrivere codice decente e non solo copiare una ricetta, lascerò alcuni suggerimenti.

• Se lasciamo la codifica, ci sono molti modi per iniettare sql e non tutti richiedono di aggiungere "o" o ", quindi Addslash è fondamentalmente una soluzione zoppa usata dagli sviluppatori zoppi e non specializzati ... . (Quelli da cui non dovresti leggere il codice)

• Questo non accade molto, ma in realtà c'è un vettore in cui l'attaccante può sfruttare una dichiarazione preparata, in alcuni motori db. Non è comune, ma puoi ricordare che l'istruzione preparata usa una dichiarazione ma con il tipo di colonna data metatdata, dimensione ....

• Altro solito errore di lame sta gestendo le ricerche nelle query con Mi piace ... Se scopri come funziona puoi fare alcune cose interessanti ...

Fai la tua ricerca, non fidarti mai di un input, non usare mai nulla di diverso da una dichiarazione preparata, ignora tutti quelli che ti dicono di usare escape fu ...

E dovresti essere al sicuro, ricorda che non ha senso ottenere qualcosa di diverso da quello che ti aspetti, così strong api tipizzate è tuo amico;).