Entonces, si algunas partes del código son propensas a la inyección de sql, al menos el usuario no puede escribir nada en la base de datos si usa la interfaz que no tiene acceso de escritura universal a todo.¿Es una buena práctica de seguridad tener usuarios separados de lectura y escritura para una base de datos?
Sí, yo diría que es una buena práctica tener los usuarios se conectan mediante cuentas que sólo permiten los privilegios mínimos necesarios para utilizar el sitio. Si los usuarios de su sitio web solo deberían leer datos de la base de datos, definitivamente crearía una cuenta que solo tenga acceso de lectura y les haga llegar al DB a través de eso.
Lo más importante sería asegurar su aplicación web. Todavía puede ser víctima de un devastador ataque de inyección SQL, incluso si un usuario no escribe en su base de datos (piense en el robo de números de tarjetas de crédito o contraseñas).
Buen punto para leer el acceso es bastante peligroso también. – Yasser1984
El enfoque generalmente es tener diferentes roles, en realidad no usuarios en sí. En cuanto a los ataques de inyección SQL, me concentraría en solucionar el problema directamente en lugar de mitigarlo a través de este enfoque que usted propone.
Sí, sin embargo, hay muchas técnicas de diseño que pueden ayudar a controlar su interfaz de base de datos y su área de superficie.
Uno debe asumir que el código general, utilizará el mismo inicio de sesión para todas sus operaciones en un determinado período de sesiones (lectura y escritura). Sin embargo, si un usuario no es un usuario de escritura, el inicio de sesión utilizado para su sesión no debería tener ningún derecho de escritura.
Una buena manera de reducir el área de superficie expuesta a la inyección de SQL es no tener en cuenta que sea capaz de actualizar las tablas directamente en el primer lugar.
Con acceso de escritura a través de procesos almacenados, por ejemplo, la única inyección que puede suceder es ejecutar esos procedimientos con los parámetros apropiados.
Por lo tanto, los procedimientos deberán ejecutarse bajo un usuario diferente con permisos de escritura, y solo serán ejecutables por el usuario de "solo lectura". esa es una buena idea también, estoy seguro de que mysql lo admite, probablemente el resto también. – Yasser1984
@ user893730 Se otorgarán los procedimientos para ejecutar el rol de usuario de la aplicación. Normalmente, lo que me gusta es la función de usuario de la aplicación con menos privilegios: seleccionar vistas, ejecutar procedimientos, nada más. http://dev.mysql.com/doc/refman/5.6/en/grant.html Puede ejecutar EXECUTE en una rutina pero no tener derechos sobre los objetos que se encuentran debajo. –
La mayoría de las veces esto es una exageración, pero la mayoría de las veces se debe utilizar consultas parametrizadas que no son propensos a la inyección de SQL de todos modos.
considerar el uso de procedimientos almacenados, y una cuenta de usuario que sólo puede llamar a procedimientos, no se ejecutan consultas directamente.
Si necesita utilizar consultas directas, y no puede usar parámetros por algún motivo, entonces sí, debe tener una cuenta de usuario que solo pueda leer desde la base de datos cuando sea posible.
Defensa en profundidad, plan de falla. Se han encontrado vulnerabilidades en las bibliotecas de consultas parametrizadas. – rook
Sí. Además de las buenas respuestas de Abe y Cade Roux, puede ayudar a los auditores de seguridad a priorizar y facilitar la investigación forense después de un ataque.
Le permite concentrar sus auditorías de seguridad en código que usa más privilegios: puede pasar más tiempo auditando código que necesita privilegios de escritura que el código que necesita privilegios de lectura, e incluso más tiempo en código que requiere privilegios de colocar tablas.
Otra propiedad agradable de la separación de funciones es que facilita la investigación forense. Si tiene una separación de roles y puede identificar el ataque en los registros de DB, puede restringir qué código podría haberse explotado: solo ese código que usa la función asociada con el ataque en los registros.
Parece que su idea de inyecciones SQL procedentes de ese cómic tonta de las Tablas Bobby.
Pero en realidad, solo una lectura de la base de datos puede ser más desastrosa que escribir.
Además, tengo la fuerte sensación de que NADIE de buenos amigos que dijeron "es una buena práctica" lo utilizó en la vida real. Digamos, una interfaz (en la vida real, no imaginaria) también debe tener acceso de escritura.
Estás ladrando árbol equivocado.
Si tiene algunas partes del código propensas a la inyección sql - CORREGIR ESTAS PIEZAS. Esa es la única solución sensata.
Un poco duro pero me encantó el http://bobby-tables.com/ lool – Yasser1984
No debe haber partes del código propensas a la inyección de SQL. Si crees que algunos son, entonces cámbialos. Restringir los privilegios de lectura/escritura no será suficiente. – Ben
Es un buen punto, pero en este caso estoy trabajando en un sitio web asp arcaico que básicamente no tiene desinfección ni nada de eso, así que antes de entrar en la corrección de guiones antiguos estaba pensando que esto podría ser un buen comienzo – Yasser1984