Modo de depuración para una aplicación pero eliminado en producción

Question

Modo de depuración para una aplicación pero eliminado en producción

#1 de pdubs (1 votos)
#2 de Thomas Pornin (0 votos)

2

Una aplicación utiliza la depuración como booleana para completar el inicio de sesión, contraseña para la autenticación.

El código es algo así:

if (ContantsFile.CUSTOM_DEBUG_FLAG) //static final
{
//disable access control ==> admin mode (admin section are now visible for anybody)
}

La aplicación está codificada en JAVA. Y la clase constants.class es diferente entregada en producción.

Tengo la sensación (disculpe, todavía soy un novato en el campo) de que este patrón es un defecto de seguridad por la siguiente razón: - Si un atacante puede cambiar las constantes.clase en producción, toda la aplicación será vulnerable

Obviamente, es una mala práctica para un punto de vista de DEV (soy un desarrollador).

¿Tienes una mejor explicación o argumentos? Esos desarrolladores me responderán que si un atacante tiene acceso a su archivo, ya está dentro de la aplicación y podría cambiar cualquier cosa.

Gracias de antemano

Frenchy

code-review

pregunta Omar Elfada 28.12.2011 - 15:27

fuente

2 respuestas

Lea otras preguntas en las etiquetas code-review

¿Qué tan seguro es Goodlink para teléfonos móviles en comparación con Activesync? Autenticación basada en tokens y ataques de paso de hash

score 1 · Answer 1

En el código que publicaste, el nombre de usuario y la contraseña podrían extraerse fácilmente del binario compilado.

Si lo va a hacer de esta manera, use una directiva de preprocesador como #if DEBUG para que el código no se compile en una versión de lanzamiento.

Esto todavía deja a tus otros entornos vulnerables, por lo que no codificaría en absoluto el nombre de usuario y la contraseña y, en cambio, utilizaría un administrador de contraseñas para completarlos automáticamente. Además, un nombre de usuario y una contraseña de desarrollo probablemente no deberían ser válidos en un sistema de producción.

score 0 · Answer 2

El lenguaje de programación utilizado en este código puede importar.

Si utiliza Java y el campo CONSTANTS.debug se declara con static final , entonces el compilador de Java (que convirtió los archivos .java en .class archivos) realmente propagó la constante booleana en el código y optimizó la sección de código; La parte con el inicio de sesión y la contraseña precargados se ha ido y el atacante no puede resucitarla. Puede verificarlo buscando el nombre de inicio de sesión en los archivos .class (abra el archivo .jar , que es solo un archivo Zip con otro nombre, y ejecute un simple grep en los archivos .class : en Java, las cadenas literales y la codificación UTF-8 en los archivos .class , por lo que grep los ubicará).

Con otros idiomas, su kilometraje puede variar. Cualquier compilador de C decente debería propagar las constantes (al menos aquellas definidas como macros) y optimizar el código muerto (es decir, el código que, después de la sustitución de la macro, se ve como if (0) { ... } ).

Los desarrolladores tienen razón en el siguiente sentido: si los atacantes pueden modificar el código de la aplicación a voluntad, entonces ya tienes problemas más grandes.

Sin embargo, tenga en cuenta que tener un inicio de sesión y una contraseña codificados en el código source significa que un atacante que obtenga acceso de solo lectura a ese código fuente podría aprenderlos. Así que tienes que preocuparte por la seguridad física de tus copias de seguridad. Como @pdubs señala, los pares de inicio de sesión y contraseña utilizados para el desarrollo no deben ser válidos en el sistema implementado (lo que anularía ese problema).