¿Cómo evitar mysql_real_escape_string para explotar una vulnerabilidad de SQLi?

Question

¿Cómo evitar mysql_real_escape_string para explotar una vulnerabilidad de SQLi?

#1 de George Bailey (2 votos)

5

Intenté encontrar algunas vulnerabilidades de inyección de SQL que podrían pasar por alto funciones que deberían evitar las vulnerabilidades de inyección de SQL, por ejemplo, mysql_real_escape_string . Encontré un exploit y el autor describió la vulnerabilidad y publicó el código vulnerable:

<?php
 if(isset($_GET['pagename'])){
  $name=$_GET['pagename'];
  $query=sprintf("SELECT* FROM ".PREFIX."page WHERE
  pagename = '%s' AND publish = 'Y'",$xx_con->real_escape_string($name));
}

Pero no describió cómo pasar por alto la protección, es decir, la función real_escape_string . ¿Existe una vulnerabilidad real de SQLi en el código y cómo podría un atacante explotarlo?

web-application sql-injection exploit php mysql

pregunta user126623 24.08.2016 - 18:37

fuente

1 respuesta

Lea otras preguntas en las etiquetas web-application sql-injection exploit php mysql

¿Cómo funciona la “protección de entrada de contraseña / teclado”? ¿Los motores de búsqueda verifican los certificados HTTPS y, de ser así, con qué CA?

score 2 · Answer 1

Actualización: vea los comentarios a continuación sobre la implementación adecuada.

Respuesta original , antes de saber que esto era oficialmente documentado :

El uso de la función real_escape_string con la sustitución %s dentro de   una cadena ya citada '%s' parece altamente sospechosa.

Podría haber una vulnerabilidad si


si real_escape_string no está diseñado correctamente,

o no se utiliza de acuerdo con su documentación. (uso incorrecto, tal vez con comillas adicionales ' o algo más)

Recomendaría encarecidamente usar un método más estándar para resolver SQLi en PHP. Uno que involucra ? de sustitución es el mejor. Sin embargo, puede Ser otro método de codificación de sonido disponible. Tales métodos suelen añadir sus propias cotizaciones internamente, en cuyo caso agregando comillas ' en su el código sería innecesario.

Noté otra cosa sobre ese código. ¿De dónde viene PREFIX ? ¿desde? Si esto es proporcionado por el usuario, obviamente tiene un SQLi vulnerabilidad. Por otro lado, si es simplemente un código duro o valor bien saneado, entonces estás de acuerdo con eso.