¿Qué tan peligroso es proporcionar un medio para que el público ejecute consultas SELECT en una base de datos?

Question

Supongamos que hago lo siguiente:

• puedo crear una base de datos MySQL, y rellenarla con algunos datos.
• Creo un usuario de MySQL que solo tiene acceso a esa base de datos y que solo tiene privilegios SELECT.
• Creo una página web a través de la cual un usuario (cualquier usuario, sin contraseña) puede ingresar SQL arbitrario, y al enviar el formulario, un script intenta ejecutar el SQL como el usuario de MySQL que creé; cualquier conjunto de resultados generado se muestra al usuario; cualquier mensaje de error generado se muestra al usuario.
• Supongamos que la base de datos no contiene procedimientos almacenados, etc., solo tablas y vistas, y que me complace que cualquiera pueda ver el contenido de esa base de datos específica.

Suponemos que la configuración será probada por un usuario malintencionado. ¿Qué es lo peor que podría pasar?

Algunos pensamientos:

• MySQL proporciona diversas declaraciones como la demostración etc., que un usuario ni siquiera tener sólo privilegios de SELECT podrían utilizar para recopilar información sobre el servidor de base de datos o de mis bases de datos. Se puede obtener otra información de los mensajes de error. Aunque probablemente no sea suficiente para obtener acceso inapropiado, esta información seguramente podría ayudar a hacerlo.
• Puede haber fallas en el software de la base de datos, o en mis scripts, o en el lenguaje de scripting en sí, que podrían permitirle a un visitante hacer cosas que no deberían poder hacer a través de esta interfaz.
• Hacer esto podría violar un acuerdo de términos de servicio, especialmente si estoy usando alojamiento compartido.

Answer 1

Hmmm. los usuarios inteligentes, pueden atacar a través de una sintaxis como:

select some_function_that_updates() from some_table; 

Y hay un ataque denial of service que podrían soplar memoria, como:

select * from some_massive_table cross join some_other_massive_table; 

Y francamente, es bastante difícil para los programadores con experiencia para escribir consultas que se comportan bien. .. qué posibilidad tiene un usuario pobre incluso si intenta escribir una buena consulta

Answer 2

Para que esto funcione, debe escribir una aplicación "shell" que realmente haga las consultas. No va a liberar a la gente en SQL Server directamente. Es grosero.

MySQL proporciona diversas declaraciones como la demostración etc., que un usuario ni siquiera tener sólo privilegios de SELECT podrían utilizar para recopilar información sobre el servidor de base de datos o de mis bases de datos.

No las ejecute en su caparazón.

Se puede obtener más información de los mensajes de error. Aunque probablemente no sea suficiente para obtener acceso inapropiado, esta información seguramente podría ayudar a hacerlo.

No mostrarlos desde su caparazón.

Puede haber fallas en el software de la base de datos, o en mis scripts, o en el lenguaje de scripting, que podrían permitirle a un visitante hacer cosas que no deberían poder hacer a través de esta interfaz.

No haga nada con privilegios "elevados". No ejecute nada más que SELECCIONAR en su caparazón.

Hacer esto puede violar un acuerdo de términos de servicio, especialmente si estoy usando alojamiento compartido.

realmente poco probable. Y. No nos preguntes este tipo de pregunta. No lo sabemos Lea su contrato.

---

Lo que has olvidado.

Un mal diseño SELECT * FROM table, table, table, table puede hacer una combinación externa de miles de millones de filas, convirtiéndose efectivamente en un ataque de denegación de servicio.

Por lo tanto, debe habilitar todas las características "de cuota de recursos" en el sistema operativo, y en SQL Server. Cada cuota debe establecerse lo más pequeña posible y cualquier problema de cuota de recursos conduce a un tipo de página de error inmediata de "demasiados datos". Sin excepciones. Sin soluciones.

Answer 3

Qué es lo peor que podría pasar?

datos conocidos Noone. Ni siquiera las personas que crearon el motor de base de datos pudieron decir con certeza absoluta lo que sería posible.

Lo que es cierto, sin embargo, es que va a eliminar una capa de protección. Ya no tiene una capa fuera de la base de datos que puede filtrar la entrada. Confía plenamente en la capacidad de la base de datos para protegerse y no está diseñada para ser una interfaz de usuario pública.