Serie Coders Conquer Security OWASP Top 10 API: Funciones de seguridad desactivadas/Funciones de depuración activadas/Permisos inadecuados

Aunque la mayoría de las vulnerabilidades de esta lista son bastante específicas de las API, el problema de las funciones de seguridad desactivadas, las funciones de depuración activadas y los permisos inadecuados puede ocurrir en cualquier lugar. Es probable que sea un poco más frecuente en las API, pero los atacantes suelen intentar encontrar fallos sin parchear y archivos o directorios desprotegidos en cualquier parte de una red. Encontrarse con una API que tiene la depuración activada o las funciones de seguridad desactivadas solo facilita su labor malintencionada. Peor aún, existen herramientas automatizadas para detectar y explotar configuraciones de seguridad incorrectas, por lo que si las tiene en su entorno, es muy probable que sean explotadas, razón por la cual esta vulnerabilidad figura en la lista de fallos de API peligrosos de OWASP.

Antes de empezar con la diversión, intente resolver este desafío de depuración:

¿Cómo se cuela en una API el fallo de funciones de seguridad desactivadas, funciones de depuración activadas o permisos inadecuados?

Para entender cómo se añade a las redes este fallo de API multidimensional, debemos desglosarlo en sus componentes. Empecemos por el problema de las funciones de depuración activadas. La depuración es una herramienta útil que ayuda a los desarrolladores a averiguar por qué las aplicaciones no funcionan correctamente o dan errores. Con la depuración activada, los errores y las excepciones generan páginas de error detalladas para que los desarrolladores puedan ver qué ha fallado y solucionar los problemas. Es perfectamente aceptable tener esto activo mientras una aplicación está en fase de desarrollo.

Sin embargo, hay una razón por la que la mayoría de los marcos de trabajo incluyen advertencias sobre la ejecución del modo de depuración en un entorno de producción, probablemente justo en el código donde se activa la depuración. Por ejemplo:

# ADVERTENCIA DE SEGURIDAD: ¡no ejecute con la depuración activada en producción!
DEBUG = True

En este ejemplo, se ha activado la depuración. La aplicación Django generará páginas de error detalladas cuando se produzca una excepción. Si esto se hace en un entorno de producción, un adversario tendría acceso a estas páginas de error, que incluyen metadatos sobre el entorno. Aunque la mayoría de los marcos de trabajo tienen la depuración desactivada por defecto, es fácil olvidar volver a desactivarla si se activó durante un largo proceso de desarrollo. Entonces, cuando la aplicación pasa a un entorno de producción, proporciona a los atacantes mucha información sobre cómo comprometer una aplicación, o incluso un servidor o una red completos.

Aunque activar el modo de depuración es principalmente un problema aislado, las vulnerabilidades de permisos inadecuados y funciones de seguridad desactivadas suelen ir de la mano. Por ejemplo, en un caso real proporcionado por OWASP, un atacante utilizó un motor de búsqueda para encontrar una base de datos que estaba conectada accidentalmente a Internet. Debido a que el popular sistema de gestión de bases de datos utilizaba su configuración predeterminada, la autenticación estaba desactivada. Así, al combinar las vulnerabilidades de permisos inadecuados y funciones de seguridad desactivadas, el atacante obtuvo acceso a millones de registros con información de identificación personal (PII), preferencias personales y datos de autenticación.

Eliminación de las vulnerabilidades de funciones de seguridad desactivadas, funciones de depuración activadas y permisos inadecuados

Probablemente necesite un enfoque doble para eliminar esta vulnerabilidad. Para solucionar la parte del problema relacionada con la depuración activada, simplemente añada una comprobación al proceso de desarrollo para asegurarse de que la depuración esté desactivada antes de trasladar una API o aplicación al entorno de producción. Según nuestro ejemplo, el comando adecuado para hacerlo sería el siguiente:

# ADVERTENCIA DE SEGURIDAD: ¡no ejecute con la depuración activada en producción!
DEBUG = False

Ahora, las funciones de depuración en la aplicación Django están desactivadas con la bandera DEBUG configurada en False. No se generarán páginas de error en respuesta a los fallos. Si un adversario logra acceder a las páginas de error, estas no contendrán metadatos útiles y no supondrán un riesgo para la aplicación.

Eliminar las vulnerabilidades de funciones de seguridad desactivadas y permisos inadecuados es un poco más difícil porque pueden abarcar una amplia gama de fallos específicos. La mejor manera de detenerlos es desarrollar un proceso estándar y repetible que permita el despliegue rápido y sencillo de activos protegidos en el entorno de producción.

Incluso entonces, debe crear un proceso en el que los archivos de orquestación, los componentes de la API y los servicios en la nube, como los permisos de los buckets de Amazon S3, se revisen y actualicen constantemente. Esta revisión también debe evaluar la eficacia general de los ajustes de seguridad en todo el entorno a lo largo del tiempo para garantizar que la organización mejore continuamente la seguridad de sus API.

Consulte las páginas del blog de Secure Code Warrior para obtener más información sobre esta vulnerabilidad y cómo proteger a su organización y a sus clientes de los estragos de otros fallos de seguridad. También puede probar una demostración de la plataforma de formación de Secure Code Warrior para mantener todas sus habilidades de ciberseguridad perfeccionadas y actualizadas.