¿Qué tan malo es permitir editar un campo de base de datos que contiene un sql desde un formulario?

Si realmente tiene que hacer esto, sugeriría un par de cosas:

1. Ejecute sus consultas proporcionadas por el usuario como un usuario de base de datos de solo lectura por separado. La mayoría de los DBMS tienen un sistema de permisos donde puede OTORGAR el permiso de usuario para que solo pueda ejecutarse SELECCIONE las consultas y puede restringir la tabla con la que ese usuario puede ejecutar.

2. Si alguna de sus tablas contiene una combinación de datos confidenciales y no confidenciales (por ejemplo, la tabla de usuarios contiene hashes de contraseña), es posible que desee crear una VISTA sobre esa tabla para ocultar los datos confidenciales. OTORGARÍA el privilegio de usuario para esta VISTA en lugar de la tabla subyacente. Alternativamente, puede otorgarle al usuario acceso a la función / procedimiento almacenado seleccionado que los filtra sin dar permiso a la tabla subyacente. En algunos casos, también puede usar el privilegio de columna.

De esta manera, incluso si la cuenta de administrador está comprometida, se limita a leer solo en las tablas seleccionadas.

Esto suena como una configuración muy extraña y diría que es bastante inseguro. Por lo general, si desea guardar las consultas SQL para ejecutarlas más tarde, debe crear un procedimiento almacenado al que pueda llamar. Almacenar la consulta SQL en una tabla de base de datos parece una mala idea desde el punto de vista del rendimiento, las mejores prácticas y la seguridad.

Es una configuración tan extraña que no podría aplicar t aceptó métodos para prevenir la inyección de SQL ataques y debido a esto estoy casi seguro de que terminaría siendo una vulnerabilidad. Sin ver exactamente cómo implementa esto, es imposible decir cuál sería esa vulnerabilidad.

Para responder a sus preguntas:

1. Sin ver exactamente cómo implementas esto, es imposible decirlo con seguridad, pero si estás preguntando si existe una "posibilidad", sí, absolutamente.
2. Me gustaría ver La guía de OWASP sobre la entrada de lista blanca si se insiste en hacerlo. .

Cada vez que almacene consultas escritas en una columna de la base de datos y luego permita un acceso de 'administrador' a esas consultas, existe la posibilidad de que un mal actor pueda acceder a ellas y cambiarlas.

Como práctica recomendada, no debe almacenar consultas de texto sin formato en la base de datos. Tal vez debería cifrar la cadena cuando la almacena, o, si MySQL la admite, activar el cifrado a nivel de tabla o columna en la base de datos en sí.

Como ya han dicho otros, esta podría no ser la mejor configuración. Pero si haces esto, tengo dos recomendaciones:

• Principio de privilegio mínimo: Asegúrese de que el usuario de la base de datos que ejecuta Las consultas solo tienen el privilegio de hacer lo mínimo que necesita. ¿Debería ser solo consultas SELECT? Bueno, sólo déjalos. ¿Solo hay que leer de tres tablas? Entonces solo da acceso a exactamente esas tres tablas. Esta respuesta hace un buen punto sobre el uso de vistas para dar acceso solo a partes de tablas.

• Filtrado / validación de consultas SQL: mencionas el uso de elementos como la lista negra de ciertas palabras por seguridad. Si bien la lista negra es el camino equivocado, puede usar la validación, pero solo como una adición, no como un reemplazo, al punto anterior. La forma en que lo haría es hacer algo como esto:

  if(sql.trim().substr(0, 7) !== "SELECT ") { echo "Houston, we got a problem!" }
  

  Tenga en cuenta que esto solo es efectivo si utiliza una función que solo acepta sentencias individuales (es decir, no hay sentencias múltiples separadas por ; ).

Finalmente, si estas consultas se usan para algo más que simplemente mostrar los datos, está en graves problemas. Si realmente controlan la lógica de la aplicación, p. Ej. "enumere los usuarios con privilegios de edición" o "enumere los artículos que se pueden eliminar", no hay un final para los problemas que podría tener si se infringe una cuenta de administrador.