¿Es posible infringir una declaración preparada y procedimientos almacenados con una cadena de consulta sql insegura?

Question

¿Es posible infringir una declaración preparada y procedimientos almacenados con una cadena de consulta sql insegura?

#1 de Marko Vodopija (1 votos)
#2 de joe (1 votos)
#3 de hmrojas.p (0 votos)

1

Recientemente, cuando estaba mirando a través de un código que se parece más o menos a esto:

 $query = "call someProcedure(?,?,{$unsafeString})";

Luego hay algún código donde se prepara la lista de argumentos y después de eso, se genera una declaración preparada a partir de la cadena query

Dado que unsafeString proviene del usuario, no se está validando ni escapando y se interpola en la cadena de consulta. Me preguntaba, ¿puede ser esto una amenaza seria y cómo puede ser explotada?

Intenté agregar una segunda instrucción al final, pero parece que las declaraciones preparadas me permiten ejecutar solo la primera consulta y también intenté usar la instrucción de selección para obtener algunos valores de dB, pero parece que algunos procedimientos almacenados no permiten haz eso.

Entonces me preguntaba, ¿puedo decir que esto es seguro? ¿O hay algunas posibilidades para explotarlo?

sql-injection php mysql

pregunta user902383 22.02.2017 - 16:44

fuente

3 respuestas

Lea otras preguntas en las etiquetas sql-injection php mysql

Agregar nuevas claves a un servidor que no acepta el inicio de sesión con contraseña Problemas de acceso a VPN y riesgos de seguridad

score 1 · Answer 1

A menos que esté haciendo algo de SQL dinámico dentro de algún procedimiento o no esté utilizando mysqli_multi_query () en este punto, debería estar seguro pero como no está escapando o validando las opiniones del usuario, y si $ unsafeString se almacena en una base de datos, un atacante puede usar esto más adelante y sería difícil lugar. Por lo tanto, cambiaría a declaraciones preparadas en todo el código para que usted maneje todos los datos. incluso uno almacenado en la base de datos de forma segura.

EDITAR:

CLARIFICATION

Dependiendo de cómo maneje los datos en su aplicación, y dado que hay un lugar en el código donde no usa declaraciones preparadas, sería seguro asumir que hay otros lugares donde tampoco podría usarlos. Si, por ejemplo, maneja datos previamente almacenados con una llamada a

$query = "call someProcedure(?,?,{$unsafeString})";

existe la posibilidad de que esté manejando esa cadena de una manera insegura donde se pueda ejecutar el código inyectado en los datos. Por ejemplo, concatenar los datos con una instrucción SELECT. Este tipo de vulnerabilidad es difícil de detectar ya que puede suponer que los datos que ya están almacenados en la base de datos son seguros.

Además, al no escapar ni validar la entrada, se está abriendo a un XSS dependiendo del ataque, de curso sobre cómo manejar esos datos más adelante o.

score 1 · Answer 2

1

No hay suficiente información proporcionada. Tendríamos que ver el procedimiento almacenado en el backend para saber si esto es vulnerable o no. Aunque te diré que definitivamente es una bandera roja.

respondido por el joe 23.02.2017 - 04:56

fuente

score 0 · Answer 3

Si la entrada de datos no está validada o no está configurada, podría ser vulnerable a la inyección de SQL, ya que un Procedimiento almacenado podría tener consultas dinámicas sin datos validados o configurados, incluso si está utilizando Procedimientos almacenados, debe usar una declaración preparada. El riesgo es menos usando el procedimiento almacenado, porque deducir la lógica interna es más complicado; Las inserciones, Actualizaciones, selecciones podrían ser parte de un Procedimiento almacenado, por otra parte, si no existe una vulnerabilidad de Inyección de SQL, podría romper la lógica del Procedimiento almacenado al intentar encontrar una inyección de SQL y podría dar lugar a resultados inesperados. Creo que un argumento sin validar y sin escapar implica un riesgo y debería ser mitigado.