Coders Conquer Security OWASP Top 10 API Series - Funciones de seguridad deshabilitadas/Funciones de depuración habilitadas/Permisos inadecuados

Publicado el 11 de noviembre de 2020
por el doctor Matias Madou
ESTUDIO DE CASO

Coders Conquer Security OWASP Top 10 API Series - Funciones de seguridad deshabilitadas/Funciones de depuración habilitadas/Permisos inadecuados

Publicado el 11 de noviembre de 2020
por el doctor Matias Madou
Ver recurso
Ver recurso

Aunque la mayoría de las vulnerabilidades de esta lista son bastante específicas de las APIs, el problema de las funciones de seguridad deshabilitadas/funciones de depuración habilitadas/permisos inadecuados es uno que puede atacar en cualquier lugar. Es probable que sea un poco más frecuente en las APIs, pero los atacantes a menudo intentarán encontrar fallas sin parches y archivos o directorios desprotegidos en cualquier parte de una red. Encontrarse con una API que tenga la depuración activada o las funciones de seguridad desactivadas sólo facilita un poco su nefasto trabajo. Peor aún, existen herramientas automatizadas para detectar y explotar las desconfiguraciones de seguridad, por lo que si las tienes en tu entorno, hay muchas posibilidades de que sean explotadas, razón por la cual esta vulnerabilidad entró en la lista OWASP de fallos peligrosos de API.

Antes de entrar en la diversión, vea si puede resolver este desafío de depuración:

¿Cómo se cuela en una API el fallo de las funciones de seguridad deshabilitadas/las funciones de depuración habilitadas/los permisos inadecuados?

Para ver cómo esta falla multidimensional de la API se agrega a las redes, debemos desglosarla en sus partes componentes. Empecemos por el problema de las funciones de depuración habilitadas. La depuración es una herramienta útil que ayuda a los desarrolladores a averiguar por qué las aplicaciones no funcionan correctamente o cometen errores. Con la depuración activada, los errores y las excepciones generan páginas de error detalladas para que los desarrolladores puedan ver lo que salió mal y solucionar los problemas. Es perfectamente correcto tener esto activo mientras una aplicación está todavía en desarrollo.

Sin embargo, hay una razón por la que la mayoría de los frameworks vienen con 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 ejecutar 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 información de metadatos sobre el entorno. Aunque la mayoría de los frameworks tienen la depuración desactivada por defecto, es fácil olvidarse de volver a desactivarla si se activa durante un largo proceso de desarrollo. Luego, cuando la aplicación se traslada 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 entera.

Mientras que la activación del modo de depuración es en su mayoría un problema independiente, las vulnerabilidades de los permisos inadecuados y las características de seguridad deshabilitadas a menudo funcionan juntas. Por ejemplo, en un escenario real proporcionado por OWASP, un atacante utilizó un motor de búsqueda para encontrar una base de datos que estaba conectada accidentalmente a Internet. Como el popular sistema de gestión de bases de datos estaba utilizando su configuración por defecto, la autenticación estaba deshabilitada. Así, combinando las vulnerabilidades de los permisos inadecuados y las características de seguridad deshabilitadas, el atacante obtuvo acceso a millones de registros con PII, preferencias personales y datos de autenticación.

Eliminación de las funciones de seguridad deshabilitadas/funciones de depuración habilitadas/permisos inadecuados

Probablemente, para eliminar esta vulnerabilidad, se necesita un enfoque doble. Para eliminar la parte de depuración habilitada del problema, simplemente añada una comprobación al proceso de desarrollo para asegurarse de que la depuración está deshabilitada antes de mover una API o aplicación al entorno de producción. Desde nuestro ejemplo, el comando adecuado para hacerlo sería el siguiente:

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

Ahora las características de depuración en la aplicación Django están deshabilitadas con la bandera DEBUG configurada en False. No se generarán páginas de error en respuesta a los errores. Si un adversario aún logra acceder a las páginas de error, éstas no contendrán ningún metadato útil, y no supondrán un riesgo para la aplicación.

Eliminar las características de seguridad deshabilitadas y las vulnerabilidades de permisos inadecuados es un poco más difícil porque pueden abarcar una amplia gama de vulnerabilidades específicas. La mejor manera de detenerlas es desarrollar un proceso estándar y repetible que permita el despliegue rápido y sencillo de activos bloqueados en el entorno de producción.

Incluso entonces, debería 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 cubos de Amazon S3, se revisen y actualicen constantemente. Esta revisión también debería evaluar la eficacia general de la configuración de seguridad en todo el entorno a lo largo del tiempo para asegurarse de que la organización siempre está mejorando la seguridad de su API.

Consulte las páginas del Secure Code Warrior páginas del blog para obtener más información sobre esta vulnerabilidad y sobre 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 Secure Code Warrior para mantener todos sus conocimientos de ciberseguridad perfeccionados y actualizados.


Ver recurso
Ver recurso

Autor

Doctor Matias Madou

Matías es un investigador y desarrollador con más de 15 años de experiencia práctica en seguridad de software. Ha desarrollado soluciones para empresas como Fortify Software y su propia empresa Sensei Security. A lo largo de su carrera, Matías ha dirigido múltiples proyectos de investigación sobre seguridad de aplicaciones que han dado lugar a productos comerciales y cuenta con más de 10 patentes en su haber. Cuando está lejos de su escritorio, Matias ha servido como instructor para la formación de seguridad de aplicaciones avanzadas courses y regularmente habla en conferencias mundiales como la Conferencia RSA, Black Hat, DefCon, BSIMM, OWASP AppSec y BruCon.

Matías es doctor en Ingeniería Informática por la Universidad de Gante, donde estudió la seguridad de las aplicaciones mediante la ofuscación de programas para ocultar el funcionamiento interno de una aplicación.

¿Quieres más?

Sumérjase en nuestras últimas ideas sobre codificación segura en el blog.

Nuestra amplia biblioteca de recursos tiene como objetivo potenciar el enfoque humano de la mejora de la codificación segura.

Ver blog
¿Quieres más?

Obtenga las últimas investigaciones sobre la seguridad impulsada por los desarrolladores

Nuestra amplia biblioteca de recursos está repleta de recursos útiles, desde libros blancos hasta seminarios web, que le ayudarán a iniciarse en la codificación segura orientada a los desarrolladores. Explórela ahora.

Centro de recursos

Coders Conquer Security OWASP Top 10 API Series - Funciones de seguridad deshabilitadas/Funciones de depuración habilitadas/Permisos inadecuados

Publicado el 11 de noviembre de 2020
Por el doctor Matias Madou

Aunque la mayoría de las vulnerabilidades de esta lista son bastante específicas de las APIs, el problema de las funciones de seguridad deshabilitadas/funciones de depuración habilitadas/permisos inadecuados es uno que puede atacar en cualquier lugar. Es probable que sea un poco más frecuente en las APIs, pero los atacantes a menudo intentarán encontrar fallas sin parches y archivos o directorios desprotegidos en cualquier parte de una red. Encontrarse con una API que tenga la depuración activada o las funciones de seguridad desactivadas sólo facilita un poco su nefasto trabajo. Peor aún, existen herramientas automatizadas para detectar y explotar las desconfiguraciones de seguridad, por lo que si las tienes en tu entorno, hay muchas posibilidades de que sean explotadas, razón por la cual esta vulnerabilidad entró en la lista OWASP de fallos peligrosos de API.

Antes de entrar en la diversión, vea si puede resolver este desafío de depuración:

¿Cómo se cuela en una API el fallo de las funciones de seguridad deshabilitadas/las funciones de depuración habilitadas/los permisos inadecuados?

Para ver cómo esta falla multidimensional de la API se agrega a las redes, debemos desglosarla en sus partes componentes. Empecemos por el problema de las funciones de depuración habilitadas. La depuración es una herramienta útil que ayuda a los desarrolladores a averiguar por qué las aplicaciones no funcionan correctamente o cometen errores. Con la depuración activada, los errores y las excepciones generan páginas de error detalladas para que los desarrolladores puedan ver lo que salió mal y solucionar los problemas. Es perfectamente correcto tener esto activo mientras una aplicación está todavía en desarrollo.

Sin embargo, hay una razón por la que la mayoría de los frameworks vienen con 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 ejecutar 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 información de metadatos sobre el entorno. Aunque la mayoría de los frameworks tienen la depuración desactivada por defecto, es fácil olvidarse de volver a desactivarla si se activa durante un largo proceso de desarrollo. Luego, cuando la aplicación se traslada 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 entera.

Mientras que la activación del modo de depuración es en su mayoría un problema independiente, las vulnerabilidades de los permisos inadecuados y las características de seguridad deshabilitadas a menudo funcionan juntas. Por ejemplo, en un escenario real proporcionado por OWASP, un atacante utilizó un motor de búsqueda para encontrar una base de datos que estaba conectada accidentalmente a Internet. Como el popular sistema de gestión de bases de datos estaba utilizando su configuración por defecto, la autenticación estaba deshabilitada. Así, combinando las vulnerabilidades de los permisos inadecuados y las características de seguridad deshabilitadas, el atacante obtuvo acceso a millones de registros con PII, preferencias personales y datos de autenticación.

Eliminación de las funciones de seguridad deshabilitadas/funciones de depuración habilitadas/permisos inadecuados

Probablemente, para eliminar esta vulnerabilidad, se necesita un enfoque doble. Para eliminar la parte de depuración habilitada del problema, simplemente añada una comprobación al proceso de desarrollo para asegurarse de que la depuración está deshabilitada antes de mover una API o aplicación al entorno de producción. Desde nuestro ejemplo, el comando adecuado para hacerlo sería el siguiente:

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

Ahora las características de depuración en la aplicación Django están deshabilitadas con la bandera DEBUG configurada en False. No se generarán páginas de error en respuesta a los errores. Si un adversario aún logra acceder a las páginas de error, éstas no contendrán ningún metadato útil, y no supondrán un riesgo para la aplicación.

Eliminar las características de seguridad deshabilitadas y las vulnerabilidades de permisos inadecuados es un poco más difícil porque pueden abarcar una amplia gama de vulnerabilidades específicas. La mejor manera de detenerlas es desarrollar un proceso estándar y repetible que permita el despliegue rápido y sencillo de activos bloqueados en el entorno de producción.

Incluso entonces, debería 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 cubos de Amazon S3, se revisen y actualicen constantemente. Esta revisión también debería evaluar la eficacia general de la configuración de seguridad en todo el entorno a lo largo del tiempo para asegurarse de que la organización siempre está mejorando la seguridad de su API.

Consulte las páginas del Secure Code Warrior páginas del blog para obtener más información sobre esta vulnerabilidad y sobre 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 Secure Code Warrior para mantener todos sus conocimientos de ciberseguridad perfeccionados y actualizados.


Nos gustaría contar con su permiso para enviarle información sobre nuestros productos y/o temas relacionados con la codificación segura. Siempre trataremos sus datos personales con el máximo cuidado y nunca los venderemos a otras empresas con fines de marketing.

Para enviar el formulario, habilite las cookies "Analytics". Siéntase libre de desactivarlas de nuevo una vez que haya terminado.