Estoy buscando enlaces, o una respuesta aquí, sobre cómo configurar correctamente los permisos de la base de datos para asegurar una aplicación Django? Para ser claros, estoy buscando específicamente material que trate sobre las concesiones en la base de datos, no los permisos dentro del propio marco Django.¿Cómo configurar los permisos de la base de datos para una aplicación Django?
lo general:
grant all privileges on my_db.* to [email protected] identified by 'my_user_pass'
grant all privileges on test_my_db.* to [email protected] identified by 'my_user_pass'
supongo que si hubo un error en Django, es posible que la apertura de su base de datos cosas terribles, pero usted tiene otros problemas si no hubiera tan grande de una seguridad agujero en django.
django necesita seleccionar, insertar, actualizar y eliminar mínimamente, para operar. Si está usando test o syncdb en absoluto, también deberá poder crear tablas e índices (y tal vez el permiso de archivo para cargar dispositivos sql).
Por lo tanto, para un DB mysql, supongo que el conjunto óptimo de permisos podría ser seleccionar, insertar, actualizar, eliminar, crear, indexar y archivar. Si quisiera obtener detalles reales, podría otorgar de forma selectiva estos permisos según corresponda en el nivel de la tabla (en lugar del nivel de base de datos).
Personalmente, encuentro grant all ... más fácil de escribir.
¿Cuál es el propósito de configurar los permisos en el nivel de base de datos? Si su servidor está comprometido, el atacante podrá hacer cualquier cosa con su base de datos (porque tiene el inicio de sesión/pase) y los permisos no serán de ayuda. Si su servidor está protegido, los permisos son inútiles.
Los permisos pueden tener sentido si su servidor de bases de datos está disponible desde el mundo exterior, pero no es una buena idea hacerlo.
Al agregar permisos DB tienes la oportunidad de limitar lo que se puede lograr con ataques de inyección SQL, etc. Si el servidor web se ve comprometido, los permisos DB tienen el potencial de limitar el daño, p. es probable que no haya ninguna razón para que el inicio de sesión de la aplicación web pueda soltar la base de datos, etc. – emru
Las inyecciones de SQL son fáciles de evitar con django y no veo una gran diferencia entre borrar todas las tablas y eliminar la base de datos. De cualquier forma, perderá sus datos y deberá restaurar cualquier cosa, desde la copia de seguridad luego de eliminar la vulnerabilidad. No es obvio que los permisos de nivel de base de datos hacen que su proyecto sea más seguro. Creo que django no tiene soporte integrado para permisos de nivel DB porque es mejor esforzarse en solucionar problemas reales: XSS, CSRF, inyecciones SQL, etc. y no engañarse a medias. –
Aquí está el consejo de Microsoft para aplicaciones ASP.NET "... Otorgue solo los permisos mínimos que la aplicación debe tener para funcionar". Y SANS "... El enfoque para esto debería ser otorgar solo los permisos mínimos que requiere la aplicación para ejecutarse". Etc Los defectos pueden estar en cualquier nivel de la pila de aplicaciones: ¿por qué no querría utilizar todas las herramientas posibles para evitar que se propague un ataque? – emru
De la documentación de Django:
https://docs.djangoproject.com/en/dev/topics/install/
"Si va a utilizar el comando manage.py syncdb de Django para crear automáticamente las tablas de bases de datos para sus modelos (después de la primera instalación de Django y la creación de un proyecto), se Deberás asegurarte de que Django tenga permiso para crear y modificar tablas en la base de datos que estás utilizando, si planeas crear las tablas manualmente, simplemente puedes otorgar permisos Django SELECT, INSERT, UPDATE y DELETE. En algunas bases de datos, Django necesitará privilegios de ALTER TABLE durante syncdb pero no emitirá sentencias ALTER TABLE en una tabla una vez que syncdb lo haya creado. Después de crear una base de datos con nosotros Con estos permisos, especificará los detalles en el archivo de configuración de su proyecto, vea BASES DE DATOS para más detalles.
Acabo de probar la configuración inicial con MySQL. Para python manage.py migrate al menos necesita los siguientes subvenciones para una operación sencilla (si yo uso db-preparación):
Y, por el camino - la seguridad importa. Puede reducir el impacto del ataque al limitar la exposición del sistema. En este caso, puede restringir 'DROP', que es bastante más. Si deja algún agujero difícil con la capacidad de inyectar SQL, probablemente reduzca el daño. Voy a investigar en el futuro si no hará ningún daño eliminar la palabra clave DELETE, lo que limitaría las posibles amenazas también. Solo porque todos dejamos errores de vez en cuando :)
Gracias Seth. Hago eso también. Sin embargo, estaba buscando el "verdadero significado" como lo pones.Hace un tiempo vi algo en la web que cubría esto en detalle y parecía que valía la pena endurecerse. Lamentablemente no lo marqué como favorito ... – emru
Esto es evidente, pero después de lo anterior: 'privilegios de descarga;' – mlissner
@mlissner ¿Puede explicar por qué? –