¿Alguna amenaza / inyecciones de SQL posibles, cuando se escapa una comilla simple?

Question

¿Alguna amenaza / inyecciones de SQL posibles, cuando se escapa una comilla simple?

#1 de tim (2 votos)

0

Digamos, cuando la aplicación del lado del servidor (como WordPress) aplica add_magic_quotes a todos los parámetros GET / POST ( $_GET = add_magic_quotes($_GET); ), por lo que llama a la url:

example.com/?id=a'b

la aplicación ahora tiene variables seguras, y la ejecución de la consulta SQL parece que ya no es perjudicial:

$id = $_GET['id']; //----> a\'b 
$mysql->query("Select .....   where id='$id'");

¿Hay algún caso, cuando todavía puede ser una amenaza para la seguridad? Cualquier ejemplo, por favor? ¿Cómo puede ser insegura esa consulta SQL, ya que se ha escapado de \' carácter dentro de $id ?

webserver php wordpress

pregunta T.Todua 20.10.2018 - 14:39

fuente

1 respuesta

Lea otras preguntas en las etiquetas webserver php wordpress

¿El exploit XSS siempre es ilegal? [cerrado] ¿Hay alguna lista de vulnerabilidades y sus firmas?

score 2 · Answer 1

Hay un par de (posibles) problemas:

Todo lo que no proviene de GET / POST sigue siendo un peligro (las posibles fuentes pueden ser archivos, correos electrónicos, bases de datos, etc.).
Las consultas SQL en las que necesita eliminar la cotización o no necesitan una cotización en primer lugar (por ejemplo, en LIMIT , para los valores de id (por ejemplo, SELECT from x WHERE id = $_GET['x'] )) o transformar aún más la entrada (por ejemplo, en IN ).
Problemas de codificación (consulte, por ejemplo, addlashes bypass a través de caracteres multibyte ).
Escape incorrecto (p. ej., no escapa también \ ).
Eliminación de comillas en otros lugares del código (al agregar comillas en la entrada se enmascaran sus datos; en algunos lugares, es posible que necesite datos limpios, que luego podría transmitir y seguir procesando; en algún lugar de la línea, esto podría terminar en una consulta).

Como mencionó WordPress: los complementos de WordPress que tienen vulnerabilidades de inyección de SQL deben demostrar que agregar citas mágicas no es suficiente en todas las situaciones.

Escapar como defensa contra la inyección de SQL es solo un desastre (tanto la seguridad como la facilidad de uso). Si está creando una nueva aplicación, solo use declaraciones preparadas (son el estándar por una razón). Sin embargo, si tienes una aplicación heredada, usar el escape con cuidado puede ser suficiente.