Implicaciones de dejar la IU de administrador accesible para usuarios que no son administradores

Debe decir una pregunta autoexplicativa escrita por un hombre que sabe exactamente lo que quiere. Ya tienes algunas buenas respuestas, contribuyendo con mi centavo como se muestra a continuación.

1. Es extremadamente común que los desarrolladores / evaluadores (empleados) tengan acceso a la base de código; sin embargo, deben tomarse precauciones, ya que, si existen claves de cifrado, no formarán parte del código normal, no habrá contraseñas de texto simple en el código. etc.
2. Es una práctica recomendada permitir que las personas tengan acceso solo a la información que necesitan para realizar tareas, nada más ni nada más, ya que puede causar fuga de datos / violación de la confidencialidad / violación en el principio de privilegios mínimos, etc.
3. Si un atacante puede ver el código del lado del cliente que no se supone / no puede usar, podrá crear un plan de ataque basado en los datos disponibles (nombre de formulario, nombre y tipos de datos de los campos, secuencia en la que son consultados, los valores predeterminados, los comentarios de desarrollo, etc. Confíe en mí si tuviera todos estos detalles, nada me puede impedir tomar el sitio con esfuerzos dedicados)
4. Sí, si este es el caso actualmente, debe abordarse de inmediato.
5. Si se trata de un software abierto, también hay escenarios que se deben considerar, como si los datos confidenciales están presentes en el código (contraseñas de usuario, claves de cifrado, detalles de comunicación externa, etc.). Si es así, entonces esto debe manejarse en un repositorio que no sea accesible para todos. Si le está dando un entorno de desarrollo a los empleados, haga valores ficticios de estos (depuración de datos) y luego presione para las personas.
6. Esto fue todo sobre el repositorio de código, venir datos / aplicación y habrá roles, grupos y permisos para la segregación del acceso que es obligatorio tanto desde la perspectiva de DB como del código; si no lo hace, faltará el control de acceso a nivel de función (usted no quiero tener eso).

Ok, he escrito demasiado, para resumir si mantiene la aplicación como está manteniendo a los atacantes (internos / externos) optimistas para que la aplicación sea vulnerable a todos los 10 riesgos principales de OWASP.

Soluciones (nunca les preguntaste pero no quiero mantener el bucle abierto)

1. Repositorio de códigos separados para configuraciones, use configuraciones ficticias en el entorno de desarrollo.
2. Nunca deje algo abierto / legible en el entorno de producción para las personas que no deberían verlo.
3. Incluso si parece estar abierto ahora, una vez que esté abierto para externos, necesitarás permisos y medidas de control de acceso, implementalos ahora y no tendrás que preocuparte por modificar la arquitectura después de un año o dos cuando el código ha crecido.
4. No dé pistas / comentarios / código en las páginas de producción que es Goldmine para los atacantes.
   5. Siga las 10 principales pautas de manejo de riesgos de OWASP.

Puedo agregar más, pero creo que esto sería suficiente por ahora.

  

¿Cuál sería el beneficio para un atacante si pudiera ver el código del lado del cliente que no se supone / está permitido usar?

Puede ser más fácil explotar vulnerabilidades como CSRF o falta de control de acceso si un atacante tiene acceso al código del lado del cliente y, por lo tanto, a las solicitudes que pueden realizarse.

También puede ser más fácil encontrar vulnerabilidades como XSS. Las vulnerabilidades como XSS ahora también pueden dirigirse a usuarios con menos privilegios, así como a usuarios con mayores privilegios, ya que ambos tienen acceso a la interfaz de usuario.

  

¿Tener esa funcionalidad expuesta es una práctica realmente mala que debería abordar inmediatamente?

En realidad no. Sin embargo, si no fuera necesario, no lo expondría por los motivos descritos anteriormente.

  

Si asumimos que este es un software abierto (y, en la actualidad, desde el punto de vista de los empleados), ¿ocultar las herramientas de los usuarios privilegiados sería solo una especie de seguridad por oscuridad, ya que un atacante podría verificar el código fuente de todos modos? / p>

Si es de código abierto, ni siquiera es seguridad por oscuridad, y ocultarlo no es estrictamente necesario (aunque todavía no es una mala idea, especialmente debido a la posibilidad de explotar vulnerabilidades de XSS).

  

¿Cuál sería el beneficio para un atacante si pudiera ver del lado del cliente?   ¿Código que no se supone / permitido usar?

Incluso si el pirata informático no puede / no puede usar el código que ve, aún puede obtener el beneficio de la información adicional, que utiliza para atacar su sitio más adelante . Una fuente de información particularmente valiosa es la información de JavaScript contenida en el lado del cliente. Si un hacker ve como:

1. Cómo se estructura su código
2. Se maneja la entrada
3. Se manejan los eventos del lado del cliente

él o ella obtiene información valiosa para explotar su sitio web basándose en dicha información.