Los programadores conquistan la seguridad OWASP Top 10 API-Serie: funciones de seguridad desactivadas/funciones de depuración activadas/permisos no autorizados

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.