¿Se resolverían las Referencias Directas Inseguras y la Inyección de SQL utilizando Seguridad de Fila y Cadenas de Conexión por Usuario?

Navega tus respuestas
1

Con respecto a las siguientes vulnerabilidades de OWASP:

¿Pueden solucionarse esto utilizando una base de datos que admita Row Level Security y creando cuentas de usuario reales en la base de datos para cada usuario y haciendo que inicien sesión en la base de datos como ellos mismos (a través del servidor web)?

¿Hay algún problema en este enfoque que deba conocer (que no sea el asesinato de la agrupación de conexiones)?

EDIT:

Uno obviamente necesita algún tipo de control de acceso de registro. ¿Por qué es peor mover el control de acceso a los registros desde la capa web a la capa de la base de datos, cuando está más centralizado? (Las bases de datos tienden a vivir más tiempo que las aplicaciones, y las bases de datos a veces tienen más de una aplicación).

La autenticación de usuario (almacenamiento) ocurre en un sistema diferente.

Los usuarios no son superusuarios y tendrían los privilegios mínimos requeridos (por eso quiero decir que no pueden ejecutar shells de comando en SQL u otras tonterías).

Los usuarios no tendrían acceso directo a la base de datos, solo acceso a través de una aplicación web.

Usaría roles jerárquicos.

Todavía usaría consultas parametrizadas, sin embargo, no todas las consultas son parametrizables, los desarrolladores cometen errores y los sistemas como Wordpress han demostrado que los complementos pueden obtenerlo.

    
pregunta Neil McGuigan 22.03.2015 - 23:32
fuente

2 respuestas

3

No efectivamente, no. Siempre tendrá casos en los que la seguridad a nivel de fila no puede emular correctamente los procesos de negocio. También deberías tener muchas cuentas de "propósito general" para cosas como el registro de usuarios. Todo sería complicado, difícil de mantener y en gran medida ineficaz.

Tenga en cuenta, también, que la inyección de SQL potencialmente no solo afecta a los datos, sino también a la base de datos. Los comandos especiales (como xp_cmdshell en TSQL, debug segfault en Redis) tienen todo tipo de impactos secundarios fuera de los datos de la fila.

En cualquier caso, la inyección de SQL es en gran medida un problema resuelto , por lo que realmente no vale la pena crear soluciones inferiores que son mucho más complejas. y costoso.

    
respondido por el Polynomial 22.03.2015 - 23:40
fuente
1

No , porque la Inyección de SQL y las Referencias Inseguras de Objetos Directos incluyen el caso de "capacidad para ejecutar el SQL al que el usuario tiene acceso pero la aplicación fue diseñada para no permitir". Su método limitará la capacidad de obtener cosas fuera de sus permisos, pero en la mayoría de los casos eso incluye cosas que no están destinadas a ser abiertas, así como información del sistema a la que generalmente se puede acceder por diseño.

Lo que puede ayudar es el uso de procedimientos almacenados en lugar del código del lado de la aplicación, pero eso no es común porque hace que la aplicación general sea más estática y frágil.

    
respondido por el gowenfawr 22.03.2015 - 23:41
fuente

Lea otras preguntas en las etiquetas

Esta página de Facebook tiene un aspecto diferente: ¿intento de phishing? ¿Cómo puedo detener una cuenta que no controlo para que no envíe correos electrónicos no deseados en mi nombre a mis contactos?