database - pruebas - ¿Soy inmune a las inyecciones de SQL si utilizo procedimientos almacenados?
sql server inyeccion de codigo (7)
Digamos en base de datos MySQL (si es importante).
Además, considere el uso de acceso a bases de datos de granularidad, (también llamado 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 la instalación? REVOKE ese permiso. ¿No tienes una necesidad legítima de ejecutar como sysdba? Entonces no! Una inyección furtiva que indique al usuario "DROP DATABASE" se verá obstaculizada si no se le ha otorgado ese permiso al usuario. Entonces, todo lo que necesita preocuparse es las declaraciones SELECT con pérdida de datos.
Depende de lo que hagan tus procesos almacenados. Si dinámicamente generan SQL basado en sus parámetros, y luego ejecutan ese SQL, entonces aún eres vulnerable. De lo contrario, es mucho más probable que estés bien, ¡pero dudo en sonar 100% seguro!
Los procedimientos almacenados no son una garantía, porque lo que en realidad es vulnerable es cualquier código dinámico, y eso incluye el código dentro de los procedimientos almacenados y las llamadas generadas dinámicamente a los 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 enteros en el código dinámico).
Los beneficios de una arquitectura almacenada en gran medida (no estoy seguro de que el 100% sea realmente posible) almacenada en procesos, sin embargo, es que la inyección puede defenderse un tanto (pero no perfectamente) para el código dinámico en el lado del cliente porque:
Solo se otorgan permisos EXEC a cualquier contexto de usuario con el que se conecte la aplicación, por lo que cualquier consulta SELECT, INSERT, UPDATE, DELETE 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 las operaciones que haya definido en su capa de SP estarán incluso disponibles (no en SQL arbitrario) para inyectarse.
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 software) están la capacidad de refactorizar su base de datos sin afectar las aplicaciones, la capacidad de comprender mejor y monitorear los patrones de uso en su base de datos. un generador de perfiles y la capacidad de optimizar de forma selectiva dentro de la base de datos sin tener que implementar nuevos clientes.
No, no estarás completamente seguro. Como han mencionado otros, las consultas parametrizadas son siempre el camino a seguir, independientemente de cómo acceda a la base de datos.
Es una especie de leyenda urbana que con los procesos estás a salvo. Creo que la razón por la que las personas están bajo este engaño es porque la mayoría de las personas asume que llamarás a los procesos con consultas parametrizadas desde tu código. Pero si no lo haces, si, por ejemplo, haces algo como el siguiente, estás abierto:
SqlCommand cmd = new SqlCommand("exec @myProc " + paramValue, con);
cmd.ExecuteNonQuery();
Porque estás usando contenido no filtrado del usuario final. Una vez más, todo lo que tienen que hacer es terminar la línea (";"), agregar sus comandos peligrosos, y boom - eres regado.
(Por otro 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 una mejor forma. Sin embargo, como han mencionado otros aquí, si su proc sigue generando SQL dinámico y ejecutándolo, aún puede haber problemas.
Debo notar que no soy anti-proc. Los procs pueden ser muy útiles para resolver ciertos problemas con el acceso a los datos. Pero los procs no son una "solución genial para las inyecciones SQL".
No, ya que aún puede usar D-SQL en sus procedimientos almacenados ... y validar y restringir su entrada es una buena idea en cualquier caso.
Usted solo es inmune a las inyecciones de SQL si utiliza consistentemente consultas parametrizadas. Eres casi inmune a las inyecciones de SQL si utilizas 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 y agrega los argumentos por concatenación, aún puedo agregar una consulta aleatoria al final de uno de los campos de entrada, por ejemplo, si tiene CALL CheckLogin @username = ''$ username'', @ password = '' $ password '', con los $ -todos que representan variables directamente concatenadas, nada me impide cambiar la variable $ password para leer "''; DROP DATABASE; -".
Obviamente, si limpia la entrada de antemano, esto también contribuye a evitar la inyección de SQL, pero esto puede potencialmente filtrar los datos que no deberían haberse limpiado.
no. Si está construyendo SQL que invoca un procedimiento almacenado, sigue siendo un objetivo.
Debería crear consultas parametrizadas en el lado del cliente.