¿mysql_real_escape_string() TOTALMENTE protege contra la inyección de SQL?

En http://www.justinshattuck.com/2007/01/18/mysql-injection-cheat-sheet/?akst_action=share-this, hay una sección que dice que usted puede pasar por alto mysql_real_escape_string con ciertas codificaciones de caracteres asiáticos¿mysql_real_escape_string() TOTALMENTE protege contra la inyección de SQL?

Anulación mysql_real_escape_string() con Big5 o GBK

"cadena de inyección"
に関する追加情報:

los caracteres anteriores son chinos Big5

¿Es esto realmente cierto? Y si es así, ¿cómo protegerías tu sitio web de esto, si no tuvieras acceso a las declaraciones preparadas?

Fuente

2009-08-02 LM.

justinshattuck.com me da una advertencia de malware en Chrome, tal vez su sitio también fue pirateado. – TK123

Los caracteres en su cadena de inyección no son realmente BIG5. Algunos proveedores extendieron BIG5 para incluir kana japonés, pero el estándar no incluye kana. –

De acuerdo con Stefan Esser, "mysql_real_escape_string() [no es] seguro cuando se usa SET NAMES".

Su explicación, from his blog:

NOMBRES SET se utiliza generalmente para cambiar la codificación de lo que es por defecto a lo que necesita la aplicación. Esto se hace de una manera que mysql_real_escape_string no conoce. Esto significa que si cambia a una codificación de varios bytes que permite la barra invertida como 2nd 3rd 4th ... Byte, se encontrará con problemas, ya que mysql_real_escape_string no se escapa correctamente. UTF-8 es seguro ...

Forma segura de cambiar la codificación es mysql_set_charset, pero que sólo está disponible en las nuevas versiones de PHP

Se menciona que UTF-8 es segura, sin embargo.

Fuente

2009-08-03 02:59:29

"UTF-8 es seguro ..." lleva a otro monstruo poco conocido: la seguridad de la codificación de entrada. P.ej. ¿Verifica si la entrada (por ejemplo, GET/POST/COOKIE/...) es realmente UTF-8? ¿La verificación y conversión automática de la codificación de entrada está activa (a nivel del servidor o de la aplicación)? Etc. –

Estoy bastante seguro de que solo no funciona si usa SQL para cambiar la codificación de caracteres.

Fuente

2009-08-02 23:38:34 alex

Esto es un error del servidor MySQL informa, que se fijó camino de regreso en mayo de 2006.

Ver:

MySQL bug #8303: Los literales de cadena con caracteres de varios bytes que contienen \ lexed están incorrectamente
MySQL Bug #8317 : El introductor de conjunto de caracteres en la consulta no puede anular el conjunto de caracteres de conexión
MySQL Bug #8378: cadena escapada incorrectamente con el juego de caracteres del cliente 'gbk'
MySQL 5.1.11 changelog.

Se notificó el error en MySQL 4.1.20, 5.0.22, 5.1.11.

Si usa 4.1.x, 5.0.xo 5.1.x, asegúrese de haber actualizado al menos los números de revisión menores.

Como solución, también puede habilitar el modo SQL NO_BACKSLASH_ESCAPES que deshabilita la barra diagonal inversa como un carácter de escape de comillas.

Fuente

2009-08-03 01:14:51

Si usa 'NO_BACKSLASH_ESCAPES', entonces [** no debe ** citar sus literales usando comillas dobles" "' caracteres] (http://stackoverflow.com/a/23277864/623041). – eggyal

@eggyal, ¿puedo? pregunte por qué dice eso? Pruebe 'SELECT" O "" Hare ";' –

Siga el enlace! En el modo 'NO_BACKSLASH_ESCAPES',' mysql_real_escape_string() 'solo dobla' '' caracteres y no '" 'caracteres! – eggyal

Como han demostrado otros, mysql_real_escape_string() can be bypassed in obscure edge cases.Esa es una estrategia conocida para eludir la lógica de escape, pero podría haber otras vulnerabilidades desconocidas que aún no se han descubierto.

La forma más sencilla y eficaz para prevent SQL injection in PHP es utilizar declaraciones preparadas donde se puede, y una muy estricta lista blanca, donde no se puede.

declaraciones preparadas, cuando se usa en realidad y no emulada por el driver PDO, son demostrablemente seguro (al menos en lo que respecta a la inyección de SQL), como los que resuelven un problema fundamental con la seguridad de aplicaciones: se separan los datosdel instrucciones que operan en los datos. Se envían en paquetes separados; los valores parametrizados nunca tienen la posibilidad de manchar la cadena de consulta.

Es 2015. No escapes y concatenas nunca más. Aún debe validar sus entradas de acuerdo con la lógica de la aplicación (y del negocio), pero solo use las declaraciones preparadas.

Fuente

2015-07-30 02:19:54

¿mysql_real_escape_string() TOTALMENTE protege contra la inyección de SQL?

Respuesta

Cuestiones relacionadas