¿Puede una consulta de SQL con entrada y parámetro del usuario ser propensa a la inyección de SQL?

Question

¿Puede una consulta de SQL con entrada y parámetro del usuario ser propensa a la inyección de SQL?

#1 de atk (5 votos)

0

Me he topado con algún código en una aplicación donde (ciertos) usuarios pueden ingresar donde las condiciones. Además de esto, hay una parte de la condición donde se establece como una consulta parametrizada.

Por ejemplo:

select foo from bar where <user generated> and foo = ?

(Además de esto, la parte generada por el usuario se ejecuta a través de un filtro de ordenaciones antes de que se construya la consulta que solo permite cierta entrada)

La aplicación usa JDBC contra Mysql (Connector / J). Este controlador hace, por lo que puedo entender, el preprocesamiento de declaraciones preparadas en el lado del cliente. Si la inyección de SQL es posible, ¿sería posible "escapar" de la condición parametrizada? Tal vez con subconsultas?

sql-injection

pregunta sesamoid 06.01.2014 - 14:37

fuente

1 respuesta

Lea otras preguntas en las etiquetas sql-injection

Comparación de bcrypt y scrypt Un técnico de teléfono falso cambió mi contraseña de inicio. [cerrado]

score 5 · Accepted Answer

Sí. Casi cualquier consulta de SQL que concatene información de usuario sin formato o protegida de manera imperfecta puede ser vulnerable a la inyección.

Hay algunas restricciones. Por ejemplo, la entrada del usuario debe ser lo suficientemente larga como para ser un ataque viable (la inyección de un solo carácter puede no ser suficiente, dado el uso específico de la declaración específica en cuestión). Tiene que ser datos utilizables para el ataque (la validación de entrada puede restringir la entrada a una lista blanca conocida de valores seguros, como {1, 2, 3}). No se puede codificar en otra forma benigna (como basese64 que codifica los datos del usuario).

La regla general que debe usar es "si está concatenado, es una vulnerabilidad a menos que se demuestre lo contrario". En general, es más barato, más rápido y más fácil de arreglar que demostrar que no es una vulnerabilidad, por lo que solo debe ser corregido.