Saneamiento de consultas SQL (lista negra)

Question

Saneamiento de consultas SQL (lista negra)

#1 de Lucas Kauffman (13 votos)
#2 de Wayne In Yak (2 votos)
#3 de dr jimbob (1 votos)
#4 de jl01 (0 votos)

3

Tengo un problema / desafío siguiente:

La aplicación web (ASP.NET 3.5) instalada en la LAN corporativa y opera en SQL Server DB debe proporcionar la capacidad de generar informes personalizados. Estos informes pueden ser, básicamente, cualquier cosa desde el DB de subrayado, incluyen uniones complicadas, uniones y cualquier cosa que se pueda imaginar. (Solo selecciona, no Insertar / eliminar / soltar / actualizar)

La forma más fácil de hacerlo: permitir que el sistema ejecute consultas SQL. El administrador del sistema agregará consultas personalizadas al sistema y los usuarios "regulares" podrán ejecutarlas. Si necesitan una nueva consulta, le pedirán al administrador que cree una consulta para ellos y luego podrán ejecutarla por Id. De consulta.

El enfoque de la Lista Blanca no va a funcionar aquí (al menos no puedo ver cómo).

¿Qué pasa con la lista negra? Estaba pensando en algo así:

blackList={"--", ";", "/*", "*/", "@@", "@",
                  "char", "nchar", "varchar", "nvarchar",
                  "alter", "begin", "cast", "create", "cursor",
                  "declare", "delete", "drop", "end", "exec",
                  "execute", "fetch", "insert", "kill", "open",
                   "sys", "sysobjects", "syscolumns",
                  "table", "update"};

Una vez más, la única persona que puede crear dicha Consulta personalizada es admin (y es muy probable que tenga el control total sobre DB en cualquier caso).

Cualquier ayuda sería bienvenida.

Gracias

A

web-application appsec sql-injection injection

pregunta AaronS 18.01.2012 - 09:27

fuente

4 respuestas

2

Cuenta de solo lectura para principiantes, denegación de actualización / eliminación, etc. de los usuarios.

Personalmente me gusta usar procedimientos almacenados para tales cosas. Y si no puede confiar en sus administradores, ¿quién podría hacer lo que ellos quieran en el backend externo si su aplicación, en quién puede confiar?

respondido por el Wayne In Yak 18.01.2012 - 18:29

fuente

1

La mejor solución sería ejecutar todas las consultas utilizando una cuenta de base de datos sin privilegios sin permisos de escritura para todos los datos, permisos de solo lectura de algunos datos y permisos de lectura para datos seguros como hashes de contraseña de otros usuarios (especialmente usuarios que son administradores).

Si el usuario final proporciona alguna entrada que ingresa a la consulta SQL, asegúrese de que está usando parámetros enlazados en lugar de formateo / concatenación de cadenas, lo que potencialmente le da al usuario final la capacidad de cambiar fundamentalmente el tipo de consulta en SQL ataques de inyección.

Tenga en cuenta que las listas negras a menudo se pueden omitir muy sutilmente. Por ejemplo, si en la lista negra update , asegúrese de que UpDaTe esté en la lista negra, así como en una cadena que contenga caracteres Unicode (como úpdãtÊ) que su base de datos pueda asignar a caracteres ASCII después de pasar la lista negra.

También tenga en cuenta las otras amenazas que puede hacer un usuario final malintencionado además de alterar sus datos; que van desde el robo de sus datos (por ejemplo, la fuerza en un LIMIT 100 ) o la denegación de servicio desde una consulta que consume mucho tiempo.

respondido por el dr jimbob 18.01.2012 - 19:34

fuente

0

Ponga a sus usuarios en el rol de base de datos db_datareader. Use VIEWS para limitar lo que pueden consultar (asegúrese de especificar la lista de columnas SELECT, no SELECT * en la declaración CREATE VIEW). Publicar las vistas y lo que proporcionan. Los usuarios SELECCIONAN de la VISTA y obtienen los datos que desean.

respondido por el jl01 20.01.2012 - 19:35

fuente

Lea otras preguntas en las etiquetas web-application appsec sql-injection injection

¿Cómo proporcionar seguridad para las contraseñas almacenadas en la base de datos? [duplicar] ¿Cómo evito que los datos salgan de mi red?

score 13 · Accepted Answer

Está proporcionando una lista para sanear, que incluye soltar, crear, ejecutar, ...

Pero si solo necesita el acceso "SELECCIONAR", sería más fácil simplemente quitarle los derechos que el usuario que está ejecutando las consultas no necesita. (menos privilegiados en lugar de todos privilegiados)

Si yo fuera usted, definiría los procedimientos almacenados porque son bastante infalibles a las inyecciones. Si esto es demasiado difícil en su aplicación web, puede probar el SQL parametrizado en el que utiliza parámetros.

Nunca vayas a limpiarte y luego consulta directamente en la base de datos. El SQL parametrizado es bastante flexible y resulta en un entorno más seguro normalmente de lo que lo haría con el SQL dinámico.

¡También ten en cuenta que no debes revelar ningún error! (Sé que es seguridad a través de la oscuridad, pero el tiempo adicional que gane con ella podría permitirle detectarla).