¿Soy inmune a las inyecciones SQL si uso procedimientos almacenados?

Question

Digamos en la base de datos MySQL (si es importante).

Answer 1

No, no estarás completamente seguro. Como han mencionado otros, las consultas parametrizadas son siempre el camino a seguir, sin importar cómo acceda a la base de datos.

Es una pequeña leyenda urbana que con procs estás a salvo. Creo que la razón por la que la gente está bajo este engaño es porque la mayoría de la gente asume que llamará a los procedimientos con consultas parametrizadas desde su código. Pero si no lo hace, si, por ejemplo, hace algo como lo que se muestra a continuación, está completamente abierto:

SqlCommand cmd = new SqlCommand("exec @myProc " + paramValue, con);
cmd.ExecuteNonQuery();

Porque estás usando contenido sin filtro del usuario final. Una vez más, todo lo que tienen que hacer es terminar la línea (" ;; "), agregar sus comandos peligrosos, y boom - estás colgado.

(Dejando de lado, si estás en la web, no tomes basura no filtrada de la cadena de consulta del navegador, eso hace que sea absurdamente fácil hacer cosas extremadamente malas con tus datos).

Si parametrizas las consultas, estás en mucho mejor estado. Sin embargo, como han mencionado otros aquí, si su proceso sigue generando SQL dinámico y ejecutándolo, es posible que todavía haya problemas.

Debería tener en cuenta que no soy anti-proc. Procs puede ser muy útil para resolver ciertos problemas con el acceso a datos. Pero los procesos no son una " plata-bala solución a las inyecciones de SQL.

Answer 2

Solo eres inmune a las inyecciones de SQL si consistentemente utilizas consultas parametrizadas. Usted es casi inmune a las inyecciones de SQL si utiliza el escape adecuado en todas partes (pero puede haber y ha habido errores en las rutinas de escape, por lo que no es tan infalible como los parámetros).

Si llama a un procedimiento almacenado, agregando los argumentos por concatenación, todavía puedo agregar una consulta aleatoria al final de uno de los campos de entrada, por ejemplo, si tiene LLAMADA CheckLogin @username = '$ username', @ password = '$ password', con $ -things que representan variables concatenadas directamente, nada me impide cambiar la variable $ password para leer " '; BASE DE DATOS DE LA GOTA; - " ;.

Obviamente, si limpia la entrada de antemano, esto también contribuye a prevenir la inyección de SQL, pero esto potencialmente puede filtrar los datos que no deberían haberse limpiado.

Answer 3

Depende de lo que hagan tus procs almacenados. Si generan dinámicamente SQL basado en sus parámetros y luego ejecutan ese SQL, entonces usted sigue siendo vulnerable. De lo contrario, es mucho más probable que estés bien, ¡pero vacilo en parecer 100% seguro!

Answer 4

no. Si está construyendo SQL que invoca un procedimiento almacenado, todavía es un objetivo.

Debería crear consultas parametrizadas en el lado del cliente.

Answer 5

No, ya que aún podría usar D-SQL en sus procedimientos almacenados ... y validar y restringir sus entradas es una buena idea en cualquier caso.

Answer 6

Los procedimientos almacenados no son una garantía, porque lo que realmente es vulnerable es cualquier código dinámico, y eso incluye código dentro de procedimientos almacenados y llamadas generadas dinámicamente a procedimientos almacenados.

Las consultas parametrizadas y los procesos almacenados llamados con parámetros son invulnerables a la inyección siempre que no utilicen entradas arbitrarias para generar código. Tenga en cuenta que hay un montón de código dinámico que tampoco es vulnerable a la inyección (por ejemplo, los parámetros de enteros en el código dinámico).

Sin embargo, los beneficios de una arquitectura basada en procs almacenada en gran medida (no estoy seguro que sea del 100%), es que la inyección puede incluso defenderse de alguna manera (pero no perfectamente) para el código dinámico en el lado del cliente porque :

Solo los permisos EXEC se otorgan a cualquier contexto de usuario al que se está conectando la aplicación, por lo que cualquier consulta SELECCIONAR, INSERTAR, ACTUALIZAR, BORRAR simplemente fallará. Por supuesto, DROP, etc. no debería permitirse de todos modos. Por lo tanto, cualquier inyección tendría que ser en forma de EXEC, por lo que, en última instancia, solo estarán disponibles las operaciones que haya definido en su capa de SP (no SQL arbitrario) para inyectar en contra.

Entre los muchos otros beneficios de definir sus servicios de base de datos como un conjunto de procedimientos almacenados (como cualquier capa de abstracción en el software) está la capacidad de refactorizar su base de datos sin afectar a las aplicaciones, la capacidad de comprender y monitorear mejor los patrones de uso en su base de datos con un generador de perfiles y la capacidad de optimización selectiva dentro de la base de datos sin tener que implementar nuevos clientes.

Answer 7

Además, considere usar el acceso a la base de datos de grano fino, (también denominado generalmente Control de acceso basado en roles) El usuario principal de su base de datos debe tener exactamente los permisos necesarios para hacer su trabajo y nada más. ¿No es necesario crear nuevas tablas después de instalar? REVOCAR ese permiso. ¿No tienes una necesidad legítima de correr como sysdba? Entonces no! Una inyección furtiva que indica al usuario que " DROP DATABASE " será bloqueado si al usuario no se le ha CONCEDIDO ese permiso. Entonces, todo lo que tiene que preocuparse es de las declaraciones SELECT con pérdida de datos.