mysql_real_escape_string() COMPLETAMENTE protegge dall'iniezione SQL?

Question

Su http://www.justinshattuck.com/2007/01/18/mysql-injection-cheat-sheet/?akst_action=share-this, c'è una sezione che pretende è possibile bypassare mysql_real_escape_string con alcune codifiche di caratteri asiatici

Bypassare mysql_real_escape_string() con BIG5 o GBK

"stringa di iniezione"
に 関 す る 追加 情報:

i caratteri di cui sopra sono cinese Big5

È proprio vero? E se sì, come proteggeresti il ​​tuo sito web da questo, se non avessi accesso alle dichiarazioni preparate?

Answer 1

Secondo Stefan Esser, "mysql_real_escape_string() [non è sicuro quando viene utilizzato SET NAMES."

La sua spiegazione, from his blog:

SET NAMES viene di solito utilizzato per passare la codifica da ciò che è di default a quali esigenze applicative. Questo è fatto in modo che mysql_real_escape_string non lo sappia. Ciò significa che se si passa ad una codifica multi-byte che consente il backslash come 2 ° 3 ° 4 ... byte si ha un problema, perché mysql_real_escape_string non scappa correttamente. UTF-8 è sicuro ...

modo sicuro per cambiare la codifica è mysql_set_charset, ma che è disponibile solo nelle nuove versioni di PHP

Egli non menziona che UTF-8 è sicuro, però.

Answer 2

Sono abbastanza sicuro che non funzioni solo se si utilizza SQL per modificare la codifica del char.

Answer 3

Questo è un bug server MySQL che è stato riferito, fissato nel lontano maggio 2006.

See:

• MySQL bug #8303: letterali stringa con i caratteri multi-byte contenenti \ sono lexed in modo non corretto
• MySQL Bug #8317 : Introduttore di caratteri nella query non riesce a sostituire il set di caratteri di connessione
• MySQL Bug #8378: stringa sfuggita in modo errato con il set di caratteri del client 'gbk'
• MySQL 5.1.11 changelog.

Il bug è stato risolto in MySQL 4.1.20, 5.0.22, 5.1.11.

Se si utilizza 4.1.x, 5.0.xo 5.1.x, assicurarsi di aver aggiornato almeno ai numeri di revisione minori.

Come soluzione temporanea, è anche possibile abilitare la modalità SQL NO_BACKSLASH_ESCAPES che disabilita la barra rovesciata come carattere di escape preventivo.

Answer 4

Come altri hanno dimostrato, mysql_real_escape_string() can be bypassed in obscure edge cases.Questa è una strategia nota per aggirare la logica di escape, ma potrebbero esserci altre vulnerabilità sconosciute che non sono ancora state scoperte.

Il modo più semplice ed efficace per prevent SQL injection in PHP è quello di utilizzare le istruzioni preparate dove è possibile, e un rigoroso whitelist in cui non si può.

Le dichiarazioni preparate, quando effettivamente utilizzati e non emulato dal driver DOP, sono dimostrabilmente sicuro (almeno per quanto riguarda la SQL injection), come risolvere un problema fondamentale con la sicurezza delle applicazioni: si separano i datidal istruzioni che operano sui dati. Sono inviati in pacchetti separati; i valori parametrizzati non hanno mai la possibilità di contaminare la stringa di query.

È il 2015. Non scappare e concatenare più. Dovresti comunque convalidare i tuoi input in base alla logica applicativa (e aziendale), ma utilizzare solo istruzioni preparate.