¿Ayuda con el procedimiento almacenado elimina la inyección SQL/¿Cuáles son los beneficios de los procedimientos almacenados sobre la declaración SQL normal en las aplicaciones?

Question

Soy bastante nuevo en SQL World. Aquí están mis preguntas:

• ¿Cuáles son los beneficios de los procedimientos almacenados sobre la declaración SQL normal en las aplicaciones?
• ¿El procedimiento almacenado ayuda a eliminar la inyección SQL?
• En Microsoft SQL Server se denomina procedimiento almacenado. ¿Qué tal en Oracle, MySQL, DB2, etc.?

Gracias por su explicación.

Answer 1

Algunos de los beneficios que considero al utilizar procedimientos almacenados

• Los procedimientos almacenados encapsular código de consulta en el servidor, en lugar de dentro de su aplicación. Esto le permite realizar cambios en las consultas sin tener que volver a compilar su aplicación.
• Los procedimientos almacenados se pueden usar para una seguridad de la aplicación más definida. Puede Denegar todos los derechos en las tablas base, otorgar ejecución solo en los procesos. Esto le da una huella de seguridad mucho más pequeña para administrar.
• Los procedimientos almacenados son código compilado. Con las últimas versiones de MSSQL, el servidor hace un mejor trabajo almacenando planes de ejecución, por lo que este no es un problema tan grande como solía ser, pero aún debe tenerse en cuenta
• Los procedimientos almacenados eliminan el riesgo de inyección SQL SÓLO cuando se usan correctamente. Asegúrese de utilizar los parámetros de la forma correcta dentro del proceso almacenado; los procesos almacenados que solo están ejecutando SQL dinámico concatenados dentro de ellos no están haciendo ningún bien a nadie.

Answer 2

Los procedimientos almacenados le permiten almacenar su código sql en una ubicación fuera de la aplicación. esto le da la capacidad de:

• cambiar el código SQL sin tener que recompilar/redistrubuting la aplicación
• tienen múltiples aplicaciones utilizan el mismo procedimiento almacenado para acceder a los mismos datos.
• Restrinja a los usuarios el acceso a las tablas de lectura/escritura directamente en la base de datos.
• Desde una perspectiva de desarrollo, también permite a los DBA/programadores de bases de datos trabajar en código sql sin tener que pasar por el código de la aplicación para trabajar en él. (separación de responsabilidades esencialmente).

¿Los procedimientos almacenados protegen contra los ataques de inyección? En su mayoría, sí. En el servidor sql puede crear procedimientos almacenados que no son efectivos contra esto, principalmente mediante el uso de sp_executesql. Ahora bien, esto no significa que sp_executesql es un agujero de seguridad, solo significa que se deben tomar más precauciones al usarlo.

Esto tampoco significa que los procedimientos almacenados son la única forma de protegerse de esto. Puede usar sql parameritizado para realizar la misma tarea de proteger contra la inyección sql.

Estoy de acuerdo con otras personas Los procedimientos almacenados pueden ser engorrosos, pero también tienen sus ventajas. Donde trabajo, tenemos probablemente 20 bases de datos de producción diferentes por varias razones (no preguntes). Trabajo en un subconjunto de quizás tres, y mi compañero de equipo y yo conocemos a esos tres muy bien. ¿Cómo nos ayudan los procedimientos almacenados?La gente acude a nosotros y cuando necesitan extraer esa información de esas bases de datos, podemos obtenerla para ellos. No tenemos que pasar horas explicando los esquemas y qué datos están des-normalizados. Es una capa de abstracción que nos permite programar el código más eficiente contra las bases de datos que conocemos. Si este no es el caso para usted, entonces tal vez los procedimientos almacenados no sean el camino a seguir, pero en algunos casos pueden agregar un gran valor.

Answer 3

En su mayor parte, la inyección SQL es mucho menos probable con un procedimiento almacenado. Aunque hay ocasiones en las que desea pasar un procedimiento almacenado algunos datos que requieren que use SQL dinámico dentro del procedimiento almacenado y luego está de vuelta donde comenzó. En este sentido, no veo ninguna ventaja sobre el uso de consultas parametrizadas en los lenguajes de programación que las soportan.

Personalmente odio los procedimientos almacenados. Tener código en dos lugares inconexos es un dolor en el trasero y hace que el despliegue sea mucho más complicado. No abogo por ensuciar tu código con sentencias de SQL tampoco, ya que esto lleva a su propio conjunto de dolores de cabeza.

Recomiendo una capa DAL implementada de dos maneras.

1. Mi favorito, utilice un objeto sistema de gestión relacional (ORM). He estado trabajando con nHibernate y me encanta. La curva de aprendizaje en pendiente, pero definitivamente vale la pena el pago en mi opinión .
2. Algún tipo de mecanismo para mantener todos los códigos SQL en un solo lugar. O bien algún tipo de biblioteca de consulta que seleccione o un conjunto de clases estructuradas realmente que diseñen el SQL para usted. No lo recomiendo ya que es básicamente como la construcción de su propio ORM y es probable que no tenga el tiempo para hacerlo correctamente.

Olvídate de los procedimientos almacenados. Usa un ORM

Answer 4

Procedimientos almacenados solo directamente evite la inyección de SQL si los llama de forma paramerizada. Si aún tiene una cadena en su aplicación con el nombre del procedimiento y concatenan los parámetros de la entrada del usuario a esa cadena en su código, todavía tendrá problemas.

Sin embargo, cuando se usa exclusivamente, procedimientos almacenados le permiten agregar algo de protección adicional al permitirle deshabilitar permisos a todo menos al comando EXEC. Aparte de esto, las consultas parametrizadas/declaraciones preparadas normalmente son almacenadas en caché por el servidor, por lo que son como un procedimiento almacenado en casi todos los aspectos.

A pesar de esto, los procedimientos almacenados tienen dos grandes ventajas para las empresas más grandes:

• Ellos le permiten definir una interfaz de aplicación para la base de datos, por lo que el sistema puede ser compartido entre varias aplicaciones sin tener que lógica duplicada en esas aplicaciones.
• Mueven el código sql a la base de datos, donde puede tener fácilmente una melodía de DBA con experiencia, actualizarla y mantenerla, en lugar de desarrolladores de aplicaciones que a menudo no saben exactamente qué están haciendo con el código de la base de datos.

Por supuesto, estas ventajas no son sin costo:

• Es más difícil realizar un seguimiento de los cambios en el control de la fuente
• El código base de datos está ahora separada del código que utiliza
• desarrollador las herramientas para administrar muchos procedimientos almacenados son menos que ideales (si alguna vez abres la carpeta de procedimientos almacenados en el estudio de administración para encontrar 200 procedimientos para una base de datos, sabes de lo que estoy hablando aquí).

Answer 5

Una forma en que los procedimientos almacenados (que no usan SQL dinámico) pueden hacer que toda la aplicación sea más segura es que ahora puede establecer los permisos en el nivel de procedimiento almacenado y no a nivel de tabla. Si haces todo tu acceso a los datos de esta manera (¡y prohibes el sql dinámico!) Esto significa que los usuarios no pueden en ningún caso hacer nada en la base de datos que no está en un proceso almacenado. Los desarrolladores siempre quieren decir que su código de aplicación puede proteger contra amenazas externas, pero parecen olvidar que las amenazas internas a menudo son mucho más graves y al permitir permisos a nivel de tabla, están a merced de cualquier usuario que pueda encontrar una forma de hacerlo. consultar directamente la base de datos fuera de la aplicación (otra razón por la cual en las grandes tiendas solo dos o tres personas tienen derechos de producción sobre cualquier cosa en la base de datos, limita quién puede robar información).

Cualquier sistema financiero que use algo excepto procs almacenados, por ejemplo, está completamente abierto al fraude interno, que es una violación de los controles internos que debería evitar el fraude y no pasaría una buena auditoría.