Sentencias SQL paramétricas vs. método muy simple

Question

Cuando comencé a escribir las primeras declaraciones SQL en mis programas me sentí bastante cómodo al protegerme contra SQL-Injection con un método muy simple que un colega me mostró. Reemplazó todas las comillas simples con dos comillas simples.

Así que, por ejemplo, hay un campo de búsqueda en el que puede introducir un nombre de cliente para buscar en el menú. Si quieres entrar en

de Peter barbería

la instrucción SELECT se vería

SELECT * 
FROM Customers 
WHERE Customername = 'Peter''s Barbershop' 

Si ahora un atacante podría insertar este:

';DROP TABLE FOO; -- 

La declaración se vería como:

SELECT * 
FROM Customers 
WHERE Customername = ''';DROP TABLE FOO;--' 

No sería soltar cualquier mesa, sino buscar la customertable para la CustomerName '; DROP TABLE FOO; - la cual, supongo, no se encontrará ;-)

Ahora después de un tiempo de la escritura declaraciones y protegiéndome contra SQL-Injection con este método, leí que muchos desarrolladores usan sentencias parametrizadas, pero nunca leí un artículo donde se usó "nuestro" método. Entonces definitivamente hay una buena razón para eso.

¿Qué escenarios cubrirían los enunciados parametrizados pero nuestro método no? ¿Cuáles son las ventajas de las declaraciones parametrizadas en comparación con nuestro método?

Gracias
Philipp

Answer 1

Las consultas parametrizadas tienen más proc que la defensa de sql-injection.

1. Soluciona un problema con la fecha & tiempo formatear & análisis.
2. Puede preparar el plan de ejecución para la consulta parametrizada.
3. La protección de inyección sql.

No puedo recordar ahora para otros profesionales :).

Sin embargo, la forma "doblar todas las comillas" tiene problemas con los campos con una longitud de caracteres limitada.

Por ejemplo:

• La página tiene casilla de "apodo" que puede ser de 10 caracteres de longitud.
• El usuario inserta "No me importa": los 10 caracteres exactos.

Ahora, si duplica las comillas, el valor tiene 11 caracteres y la base de datos lo "cortará", y obtendrá otro valor en db que el usuario.

Así que recomiendo los parámetros.

Answer 2

¿Cuáles son las ventajas de instrucciones con parámetros comparados con nuestro método?

La ventaja es que es más difícil cometer un error; no puede hacer el método parametrizado y olvida reemplazar las comillas. Además, reemplazar citas es vulnerable si lo haces dos veces.

La desventaja de las consultas parametrizadas (y la razón por la que nunca las uso) es la complejidad. Puede escribir diez veces más consultas ad-hoc antes de obtener RSI.

Answer 3

Una gran desventaja es que su solución depende de que un desarrollador recuerde agregar el carácter, obviamente el compilador no se quejará. Eso es peligroso.

En segundo lugar, el rendimiento debe ser mejorado con las instrucciones SQL con parámetros, como señala Jeff cabo here (en !!!).

Answer 4

Una de las ventajas es que el propio controlador determinará qué tiene que escapar y qué no necesita ser escapado.Su método podría ser roto con una entrada como esta:

\'; DROP TABLE foo;-- 

que daría lugar a

SELECT * 
    FROM Customers 
    WHERE Customername = '\'';DROP TABLE FOO;--' 

La primera cita se escapó, el segundo no lo hace y se cierra la cadena.

Answer 5

Respuesta corta:
Debe usar consultas parametrizadas simplemente porque el servidor de la base de datos sabe mejor que usted de qué caracteres se debe escapar.

Respuesta larga:
' no es necesariamente el único carácter especial que necesita escaparse. Estos caracteres especiales difieren del servidor de base de datos al servidor de base de datos. MySQL, por ejemplo, también usa \ como un carácter de escape (a menos que se haya configurado sql_mode=NO_BACKSLASH_ESCAPES). Por lo tanto, '' y \' significan lo mismo.

Esto no es cierto para, digamos, Oracle.