¿Existen riesgos potenciales al permitir que un usuario de MySQL del sitio web de PHP tenga permisos de creación, modificación y eliminación?

Navega tus respuestas
2

Permítame ponerle un prefijo a mi pregunta con información sobre nuestro entorno. Tenemos un servidor web con más de 100 sitios web. El servidor web tiene una versión 5.7 del servidor MySQL correspondiente. Cada sitio web de PHP tiene una base de datos MySQL con un usuario de MySQL adjunto que solo tiene permisos establecidos para que pueda acceder a su base de datos. Anteriormente, solo hemos otorgado a ese usuario de sitio web, SELECT, UPDATE, DELETE e INSERT. Ahora nos encontramos en una situación en la que ahora debemos otorgarle al usuario los permisos Crear, Alterar y Eliminar. Me pregunto qué riesgos potenciales de seguridad nos ponen al otorgar estos permisos adicionales a estos usuarios de sitios web.

El primero obvio que se me ocurre es con el permiso DROP, alguien podría, obviamente, eliminar todas las tablas y todos los datos se perderían. Estoy pensando que podríamos reestructurar nuestro código para no requerir DROP. Si ese es el caso y solo necesitamos agregar CREAR & Alterar al usuario, ¿cuál es la situación del peor de los casos? La base de datos también está bloqueada por IP para que solo se pueda acceder dentro de nuestra red, por lo que la única forma en que un usuario podría acceder a la base de datos directamente sería a través de una inyección SQL a través del sitio web.

    
pregunta matwonk 02.01.2018 - 21:35
fuente

2 respuestas

1

Lamentablemente, no estoy muy familiarizado con PHP, por lo que no puedo dar una idea de cómo se puede explotar específicamente a partir del código, pero quiero señalar algunos otros detalles. Desde el punto de vista de la ingeniería de seguridad, abres una gran cantidad de oportunidades de ataque. En primer lugar, las razones para evitar el DROP son obvias. Aparte de eso, si se produce una inyección de SQL, el usuario podría haber creado un script que crea una cantidad infinita de bases de datos y potencialmente DOS en su sistema, un ataque con script que usa ALTER también puede causar un caos en su base de datos. Puede verificar algunas de esas cosas en el backend pero aún así otorgarle demasiado poder a un usuario

Es difícil proponer algo sin la fuente, pero ¿por qué no intentas aislar las acciones "peligrosas" dentro del servidor pasando la solicitud a una verificación de back-end y luego tienes una raíz u otro usuario privilegiado para modificar la base de datos? p>     

respondido por el Konstantinoscs 02.01.2018 - 22:20
fuente
1

No creo que hayas reducido significativamente la seguridad del sistema.

Anteriormente, alguien podría escribir una consulta como: 

DELETE FROM importantTable where year(now()) <> 49

Esto significa que se fuga de la protección "BORRAR TODO" que MySQL tiene, pero al final, la declaración eliminará todos tus datos, suponiendo que no vivas en la época de Julius Cesar.

Mi punto es que si existe una voluntad malévola para eliminar sus datos, su cambio no mejora las probabilidades del atacante.

Mi preocupación es más de seguridad. Suponiendo que un programador escribe un "estilo de James Bond ALTER TABLE": dejará caer la tabla y luego la recreará. Esto está bien siempre y cuando la tabla no contenga datos, pero causará la pérdida de datos.

El hecho de que se acceda a su base de datos desde PHP o desde otro sistema es irrelevante. Sin embargo, es relevante comprender la perspicacia de las personas que implementan el código. ¿Cuántas veces grabas en tus registros un DROP denegado? Esto "no debería haber ocurrido", y por el hecho de que negó DROP, es posible que haya conservado los datos.

    
respondido por el user166832 02.01.2018 - 22:43
fuente

Lea otras preguntas en las etiquetas

Desventajas a SSHing de una cuenta de root a una cuenta menos privilegiada en otro servidor Aclaración sobre la definición de Cipher Suite en Wikipedia