OWASP: Top 10 de vulnerabilidades en aplicaciones web

Las aplicaciones web forman parte de nuestro día a día. Las empleamos y consultamos en el trabajo y en casa, para informarnos y para entretenernos. Su uso se ha extendido tanto que se han convertido en un elemento básico de nuestras vidas. Desde el punto de vista de las empresas, las aplicaciones web son, en algunos casos, su canal de conexión con el mundo y, en otros, el pilar fundamental de sus negocios. Por ello, es fundamental que los desarrolladores de software estén al tanto de las vulnerabilidades en aplicaciones web más comunes. Y pongan en marcha una codificación más segura.

Teniendo en cuenta la relevancia de las webs para los usuarios, las empresas e instituciones y los desarrolladores, la Fundación OWASP publica, periódicamente, un Top 10 de vulnerabilidades en aplicaciones web. De esta forma, sistematiza, actualiza y conceptualiza los principales riesgos. Erigiéndose como un estándar básico en materia de ciberseguridad a nivel mundial.

Para ello, OWASP lleva a cabo una compleja investigación para testear aplicaciones, detectar los ciber riesgos más comunes y recopilar las mejores prácticas en seguridad. El Top 10 de vulnerabilidades en aplicaciones web de OWASP categoriza los riegos y propone una serie de acciones. Éstas pueden ser implementadas por los profesionales, para proteger sus desarrollos y poner coto a los peligros. Además, se incorporan ejemplos de escenarios de ataque.

El último Top 10 de vulnerabilidades en aplicaciones web de OWASP se publicó en 2021. Este informe ofrece una panorámica amplia de los principales riesgos de seguridad a los que tienen que hacer frente los desarrolladores y las compañías en la actualidad. A continuación, vamos a explorar una a una cada categoría de vulnerabilidades.

1. Fallos de control de acceso en OWASP

En el anterior Top 10 de vulnerabilidades en aplicaciones web del año 2017, este riesgo ocupaba la quinta posición del ranking. Sin embargo, en la última investigación realizada por OWASP, este riesgo, testeado en el 94% de las aplicaciones analizadas, mostró una tasa de incidencia del 3,81%.

Esta categoría hace referencia a las debilidades detectadas en la implementación de controles de autenticación y autorización. O, dicho de otra forma, la misión del control de acceso de una aplicación web es garantizar que los usuarios no puedan llevar a cabo acciones para las que carecen de permisos.

A la hora de programar cualquier recurso web, los desarrolladores deben tener en cuenta un esquema de controles de acceso y un sistema de permisos. En esta línea, se requiere la implementación de mecanismos de validación a la hora de acceder a cada recurso. Y así poder verificar que el usuario tiene asignado el rol que necesita para ejecutar una acción relacionada con dicho recurso.

Manipulación del valor de identificadores

Óscar Mallo, Cybersecurity Advisor de Tarlogic, destaca un ejemplo paradigmático de esta vulnerabilidad: la manipulación del valor de identificadores en los parámetros de una URL.

A través de esta acción maliciosa, se puede acceder a elementos de información que no tienen relación con el usuario autenticado. Por ejemplo, si la URL que define el acceso al recurso que permite visualizar información privada de un usuario aparece un parámetro UserId y cuyo valor es 1000, este podría ser modificado para definir el valor 1002. Si la aplicación no implementa correctamente medidas de control de acceso, sería posible recuperar información de otro usuario de forma no autorizada.

Esta operación abre la puerta a que una persona con un rol de seguridad bajo pueda tener acceso a la información y los recursos de otra con un rol de seguridad alto dentro de la organización.

En lo que respecta a los ecommerce, cada vez más relevantes a nivel socioeconómico, este tipo de vulneración podría tener consecuencias gravísimas para el negocio. Ya que, mediante un ataque, podría llegarse a manipular los precios de la plataforma, llevando a cabo fraudes con éxito.

Asignación de mínimos privilegios indispensables

¿Cómo se puede prevenir esta vulnerabilidad a la hora de programar? Óscar Mallo sostiene que «a la hora de definir los controles de autorización, se debe seguir por defecto el principio de la asignación de los mínimos privilegios indispensables». Puesto que de esta manera se reduce al mínimo la posibilidad de que se produzcan brechas de información. Asimismo, continúa Mallo, «toda acción sensible sobre una entidad de información debe llevar asociada un control de autorización que garantiza el acceso o modificación solamente a los usuarios adecuados».

Desde OWASP recuerdan que el control de acceso solo es efectivo en código del lado del servidor. Puesto que, en ellos, los atacantes no pueden modificar la comprobación del control de acceso y los metadatos. Por ello recomiendan:

• Denegar por defecto el acceso, salvo en casos de recursos públicos.
• Implementar mecanismos de control de acceso una vez y reutilizarlos en todos los recursos de la aplicación web.
• Los controles de acceso deben impedir que el usuario pueda crear, leer, actualizar o eliminar cualquier registro.
• Desactivar el listado de directorios del servidor web y garantizar que los metadatos de los archivos no están presentes en las raíces web.
• Registrar los fallos de control de acceso y alertar a los administradores si hiciese falta.
• Limitar la tasa de acceso a la API y al controlador, para acotar los daños generados por herramientas automatizadas de ataque.
• Los identificadores de sesión deben ser invalidados en el servidor cuando ésta termina.

2. Fallos criptográficos

Este tipo de riesgo asciende un puesto en el ranking con respecto al Top 10 de vulnerabilidades en aplicaciones web del año 2017. Esta categoría sistematiza los fallos vinculados con la criptografía. Y que pueden llegar a exponer datos sensibles y comprometer a los sistemas en su totalidad.

Se tratan, por tanto, de vulnerabilidades vinculadas a la ausencia de protocolos de comunicaciones seguros. Es decir, cifrados. La raíz de este problema se encuentra en la utilización de:

• Esquemas de cifrado obsoletos y/o inseguros.
• Claves de cifrado débiles.

Usar algoritmos de cifrado fuertes y plenamente actualizados

La ciberseguridad es un área en la que es indispensable mantenerse permanentemente actualizados, puesto que cada día surgen riesgos e innovaciones nuevas. En lo que respecta a la criptografía esto es aún más relevante si cabe. No basta con que la criptografía esté presente. Sino que, además, debe ser de calidad y estar plenamente actualizada. Para, así, poder responder con éxito a los ataques que se van desarrollando.

Esto es debido a que los algoritmos, como sostiene José Rabal, Security Advisor de Tarlogic, van quedándose obsoletos con el paso del tiempo.

A la hora de prevenir estas vulnerabilidades, OWASP recomienda:

• Clasificar los datos procesados, almacenados o transmitidos por una aplicación, identificando los datos especialmente sensibles, y aplicar controles de seguridad en función de dicha clasificación.
• Evitar el almacenamiento de datos sensibles que no son necesarios o eliminarlos lo antes posible.
• Cifrar todos los datos sensibles almacenados.
• Utilizar una gestión de claves adecuada a las necesidades de la aplicación web.
• Encriptar los datos en tránsito con protocolos seguros, priorizando el cifrado por parte del servidor.
• Desactivar el almacenamiento en caché de las respuestas que incluyen información sensible.
• Almacenar las contraseñas mediante funciones de hashing fuertes y adaptativas.
• Utilizar el cifrado autentificado.
• Generar las claves criptográficamente de forma aleatoria y almacenarlas en memoria como byte arrays. Asimismo, hay que asegurarse de que la aleatoriedad criptográfica se emplea de forma apropiada y que no es predecible o con baja entropía.
• Evitar funciones criptográficas y esquemas obsoletos.
• Verificar de forma independiente que la configuración criptográfica es eficaz y segura. Mediante, por ejemplo, una auditoría de seguridad web.

3. Inyección

Si bien esta categoría desciende del primer puesto del Top 10 de vulnerabilidades en aplicaciones web al tercero, sigue siendo una vulnerabilidad relevante y con una ratio de incidencia del 3’37%.

Mediante las vulnerabilidades de inyección, los atacantes pueden aprovechar la ausencia de un correcto filtrado o saneado de los datos de entrada, para alterar el código de las funciones de la aplicación. De esta forma, se consigue que se ejecuten acciones o se devuelva información de forma inesperada. Este tipo de vulnerabilidades suele llevar asociado un impacto elevado en la seguridad de la aplicación web.

Desde OWASP consideran que una web es vulnerable a un ataque de inyección cuando:

• Los datos que introduce el usuario no son validados, filtrados o saneados.
• Las consultas dinámicas son utilizadas directamente en el intérprete.
• Los datos hostiles se utilizan dentro de los parámetros de búsqueda para extraer registros sensibles.
• Los datos hostiles se procesan o concatenan directamente.

José Rabal nos propone un ejemplo muy gráfico para entender este tipo de vulnerabilidades. Una aplicación web cuenta con un campo de búsqueda de usuarios por su nombre. Sin embargo, el atacante, en vez de escribir un nombre, introduce una cadena especialmente manipulada para alterar la consulta subyacente y conseguir que la aplicación le devuelva, además de los datos básicos del usuario, información especialmente sensible relativa a ésta y que el sistema no preveía aportar.

Vincular de forma segura los parámetros de entrada

Los expertos en ciberseguridad de Tarlogic consideran que la mejor forma de mitigar este tipo de debilidades es siguiendo los siguientes consejos:

1. Hacer uso de las funciones incluidas en la propia API o en el framework de la aplicación. Para, de esta manera, vincular de forma segura los parámetros de entrada proporcionados por el usuario.
2. Si la opción 1 no se puede implementar, se deben implementar del lado del servidor los filtros adecuados a los valores proporcionados por los usuarios. De tal forma que se garantice que no pueden alterar de forma inesperada el comportamiento de las acciones llevadas a cabo por la aplicación.

El informe de OWASP sostiene que para prevenir los ataques de inyección es fundamental mantener sistemáticamente separados los datos de los comandos y las consultas. Para ello, recomiendan:

• Utilizar una API segura que evite el uso del intérprete por completo, e implementar una interfaz parametrizada.
• Utilizar la validación positiva de los inputs del lado del servidor.
• En lo que respecta a las consultas dinámicas residuales, se debe utilizar la sintaxis de escapado de caracteres específica para el intérprete. Las estructuras SQL, como los nombres de las tablas y de las columnas, no se pueden escapar, de ahí que este problema sea común en software de escrituras de informes.
• Utilizar LIMIT y otros controles SQL en las consultas. Para evitar la divulgación masiva de filas de información si se produce una inyección SQL.

4. Diseño inseguro

Esta categoría es de nueva creación y engloba los diferentes riesgos asociados a los defectos de diseño y de arquitectura web. O lo que es lo mismo, agrupa el conjunto de debilidades derivadas de la ausencia de la aplicación de metodologías de diseño seguro.

Estas vulnerabilidades son difíciles de subsanar una vez se haya realizado el desarrollo. Tanto por la complejidad de la tarea como por el sobrecoste que supondría llevarla a cabo. En este sentido, OWASP incide en una diferencia que hay que tener muy presente. No es lo mismo un diseño inseguro que una implementación insegura.

Un diseño seguro puede verse lastrado por defectos de implementación de los que nazcan riesgos de seguridad. Mientras que las debilidades propias de un diseño inseguro no se pueden paliar mediante una implementación perfecta. Puesto que los controles de seguridad no han sido creados para defenderse de ataques específicos. Un factor clave que contribuye a que un diseño no sea seguro es la incapacidad de la organización para determinar qué nivel de diseño de seguridad se necesita.

Modelos de ciclo de vida de desarrollo seguro

Óscar Mallo y José Rabal sostienen que la mejor forma de subsanar de raíz las vulnerabilidades de diseño inseguro es aplicar modelos de ciclo de vida de desarrollo seguro de software. Dichos modelos sirven para plantear casos de uso indebido durante la fase de diseño de un sistema. Y, así, evitar errores comunes.

Esta medida también es señalada, por parte de OWASP, como la mejor manera de prevenir los riesgos asociados a un diseño inseguro. Puesto que ayuda a evaluar y diseñar los controles relacionados con la seguridad y la privacidad de la aplicación web. Otras acciones que se pueden acometer a la hora de garantizar que el diseño sea seguro son:

• Establecer y utilizar una biblioteca de patrones de diseño seguro.
• Utilizar el modelado de amenazas para la autenticación crítica, el control de acceso y los flujos clave.
• Integrar el lenguaje y los controles de seguridad en las historias de los usuarios.
• Integrar controles en cada nivel de la aplicación web.
• Escribir test de integración para validar que todos los flujos críticos son resistentes frente al modelo de amenazas. A mayores, como ya señalamos, se pueden recopilar casos de uso para cada nivel de la aplicación.
• Segregar las capas de niveles en función de las necesidades de exposición y protección. Así como a los inquilinos en los diferentes niveles.
• Limitar el consumo de recursos por usuario o por servicio.

5. Configuración de seguridad incorrecta

La arquitectura de una aplicación web se sustenta sobre una gran cantidad de elementos, los cuales presentan diversas opciones de configuración. Servidores, frameworks, sistemas gestores de datos, CMS, plugins, APIs… Todos estos elementos pueden formar parte de la arquitectura que soporta a la aplicación. Y dar lugar a vulnerabilidades de seguridad si cuentan con una configuración incorrecta, o con una configuración por defecto que no cumple con los estándares de seguridad adecuados.

Esta debilidad fue detectada en el 4% de las aplicaciones web testeadas en la investigación de OWASP. Lo que ha provocado que ascienda un puesto con respecto al Top 10 de vulnerabilidades en aplicaciones web elaborado en 2017.

Hardening, segmentación y buenas prácticas

Los consultores de ciberseguridad de Tarlogic Security recomiendan cuatro acciones básicas para mitigar las vulnerabilidades de configuración incorrecta de la seguridad:

1. Poner en marcha un proceso de hardening. Mediante éste se pueden aplicar configuraciones adecuadas sobre todos los componentes de la arquitectura.
2. Realizar, en la medida de lo posible, una segmentación entre los diferentes componentes de la arquitectura web. Así se puede evitar que una vulnerabilidad que se origina en uno de ellos pueda dar lugar a movimientos laterales de los atacantes y afectar a otros componentes.
3. Aplicar directivas de seguridad que apuesten por una defensa en profundidad de los componentes.
4. Revisar toda la documentación sobre buenas prácticas de seguridad relacionada con los diferentes elementos que componen la arquitectura. Aquí juega un papel fundamental OWASP, como estándar reconocido por la comunidad de ciberseguridad mundial, cimentado sobre las mejores prácticas realizadas en el sector.

Precisamente, esta fundación recomienda, para prevenir este tipo de vulnerabilidades, las acciones propuestas desde Tarlogic y otras tareas como:

• Desarrollar una plataforma mínima, sin componentes innecesarios, así como eliminar o no instalar características y frameworks que no son precisos.
• Contar con una tarea para revisar y actualizar las configuraciones apropiadas de todas las notas de seguridad, actualizaciones y parches.
• Diseñar un proceso automatizado para verificar la eficacia de las configuraciones y ajustes en todos los entornos.

6. Componentes vulnerables y obsoletos

Su nombre deja poco lugar a dudas. Este tipo de vulnerabilidades se origina por la utilización de software o de componentes dentro de una aplicación o infraestructura web obsoletos o con vulnerabilidades conocidas.

¿Cómo puede saber una organización que su aplicación web está en riesgo por contar con componentes vulnerables u obsoletos? OWASP señala seis escenarios que permiten a las compañías detectar este problema si:

• No se conocen las versiones de todos los componentes que se están utilizando en la aplicación web. Tanto del lado del cliente, como del lado del servidor.
• El software es vulnerable, no tiene soporte o está desactualizado.
• No se escanean las vulnerabilidades regularmente.
• No se corrige o actualiza la plataforma subyacente y los marcos de trabajo.
• Los desarrolladores de software no comprueban la compatibilidad entre las bibliotecas actualizadas o parcheadas.
• No se garantiza la seguridad de las configuraciones de todos los componentes.

DevSecOps: securizar todas las fases del ciclo de vida

Para mitigar esta vulnerabilidad, una organización puede apostar por DevSecOps, un enfoque de gestión centrado en monitorizar, analizar y aplicar medidas de seguridad en todas las fases de la vida útil de un software.

De esta manera se garantizaría que, de forma permanente, se evalúan los componentes que conforman la infraestructura de la aplicación web. Y se implementan las medidas de seguridad necesarias para evitar que sean vulnerables o queden obsoletos.

El modelo de gestión y supervisión de los componentes debe permitir:

• Eliminar los componentes, archivos y características no utilizados.
• Inventariar continuamente las versiones de los componentes, tanto del lado del servidor como del lado del cliente.
• Emplear herramientas de análisis de componentes para automatizar el proceso.
• Obtener componentes únicamente de fuentes oficiales.
• Controlar los componentes que no reciben mantenimiento o para los que no se crean parches de seguridad para las versiones más antiguas.

El objetivo final es que la organización cuente con un plan de vigilancia permanente para implementar las medidas de seguridad que sean necesarias para prevenir la aparición de vulnerabilidades.

7. Fallos de identificación y autentificación

Esta categoría se denominó Autenticación rota en el Top 10 de vulnerabilidades en aplicaciones web del año 2017. Y ocupó el segundo puesto de aquel ranking. En esta ocasión, el equipo de OWASP decidió agrupar en una sola categoría los fallos de autentificación y los de identificación, siendo detectadas este tipo de vulnerabilidades en un 2,55% de las aplicaciones testeadas.

Como señalan Óscar Mallo y José Rabal, los mecanismos de autenticación son un elemento vital para la seguridad de las aplicaciones. Ya que garantizan la identidad de los usuarios.

Esta categoría tan importante engloba las vulnerabilidades que permitirían o facilitarían la suplantación de la identidad de los usuarios, como consecuencia de una incorrecta gestión de los identificadores de sesión, o de los elementos vinculados con la autenticación en la aplicación. Entre los fallos de identificación y autenticación más relevantes podemos destacar:

• La ausencia o incorrecta implementación de múltiples factores de autenticación.
• Procesos inseguros de recuperación de credenciales.
• Escasas medidas contra ataques de fuerza bruta.
• Incorrecta renovación de los identificadores de sesión para cada autenticación válida.

Autenticación multifactor y medidas de seguridad

Para prevenir el surgimiento de fallos de identificación y autenticación, que abran las puertas a ataques maliciosos contra las aplicaciones web, OWASP recomienda:

• Implementar la autenticación multifactor para evitar ataques automatizados de fuerza bruta y la reutilización de credenciales robadas.
• No implementar credenciales por defecto.
• Poner en marcha controles para detectar contraseñas débiles y testear las contraseñas nuevas o que han sido modificadas.
• Asegurarse que las vías de registro, recuperación de credenciales y API están fortificadas frente a los ataques de enumeración de cuentas.
• Limitar y espaciar los intentos de inicio de sesión fallidos.
• Utilizar un gestor de sesiones integrado y seguro del lado del servidor.
• Evitar que el identificador de sesión esté en la URL, almacenarlo de forma segura e invalidarlo una vez que termine la sesión o se alargue el periodo de inactividad.

8. Fallos en el software y en la integridad de los datos

Este tipo de fallos están vinculados con la falta de protección del código y la infraestructura frente a las violaciones de la integridad. Esta categoría es una novedad dentro del Top 10 de vulnerabilidades en las aplicaciones web. Y sirve para poner el foco en debilidades relacionadas con:

• Ataques maliciosos a las supply chains de software.
• Plugins, bibliotecas, repositorios y redes de entrega de contenido no fiables.
• Canales CI/CD inseguros, a través de los que se puede introducir códigos maliciosos o comprometer el sistema.
• Funcionalidades de autoactualización en las que las actualizaciones se descargan sin contar previamente con un sistema seguro de verificación de la integridad. A través de esta vía de acceso, los ciberdelincuentes pueden subir sus propias actualizaciones maliciosas para distribuirlas y ejecutarlas en todas las instalaciones.

Proteger las supply chains y ejecutar labores de comprobación

De cara a prevenir el surgimiento de este tipo de debilidades, OWASP recomienda implementar las siguientes acciones:

• Utilizar firmas digitales o mecanismos similares para verificar la procedencia del software o los datos.
• Asegurarse de que las bibliotecas consumen repositorios de confianza.
• Emplear herramientas de seguridad para proteger las supply chains de software. Éstas deben verificar que los componentes no contienen vulnerabilidades.
• Confirmar que la canalización CI/CD tiene un control de acceso y una configuración seguros para garantizar la integridad de código.
• Garantizar que los datos serializados que carecen de firma o de encriptación se envían solo a clientes confiables. De cara a evitar su manipulación.

9. Fallos en el registro y la supervisión de la seguridad

Como indican Óscar Mallo y José Rabal, la trazabilidad de los eventos que ocurren en la aplicación es esenciall. En primer lugar, para bloquear amenazas. Y, en segundo, para investigar incidentes de seguridad que hayan tenido lugar y, así, evitar que vuelvan a producirse y poder concretar qué posibles activos se han visto comprometidos.

De ahí que esta categoría tenga por objetivo ayudar a los profesionales a detectar, escalar y responder a violaciones activas. Los fallos en el registro, la detección, la supervisión y la respuesta activa frente a los ataques se pueden producir cuando:

• Los eventos auditables, como los inicios de sesión o las transacciones de alto valor no se registran.
• Las advertencias y los errores no generan mensajes de registro o son inadecuados.
• Los registros de las aplicaciones y las API no se supervisan.
• Los registros solo se almacenan localmente.
• Las pruebas de penetración no activan las alertas de seguridad.
• La aplicación web es incapaz de detectar, escalar y alertar ataques en tiempo real.

Generación de logs y sus copias de seguridad

Los expertos de ciberseguridad de Tarlogic recomiendan, para hacer frente con éxito a estas vulnerabilidades:

1. Hacer uso de las propias capacidades de generación de logs.
2. Monitorizar las capacidades de generación de las que ya disponen los elementos de la arquitectura. O, en su defecto, agregar componentes adicionales que garanticen que esta tarea se lleva a cabo de forma eficaz.
3. Generar de forma periódica copias de seguridad de los logs. Así como almacenarlas sobre ubicaciones que garanticen su disponibilidad en todo momento. A pesar de los posibles incidentes que puedan materializarse.

10. Falsificación de solicitudes del lado del servidor

Este tipo de vulnerabilidades se producen cuando un atacante tiene la posibilidad de forzar al servidor a realizar conexiones hacia objetivos que no estaban previstos inicialmente. De esta manera, el atacante aprovecha la posición privilegiada del servidor en la infraestructura para:

• Evadir cortafuegos.
• Forzar conexiones a elementos de la red interna.
• Interactuar con recursos que inicialmente eran restringidos.

Esta última categoría del Top 10 de vulnerabilidades en aplicaciones web es de nueva creación y no responde tanto a los datos obtenidos tras testear aplicaciones, sino a los resultados de la encuesta realizada por OWASP a expertos en ciberseguridad de todo el mundo.

A pesar de que los datos no muestran una gran incidencia de este tipo de vulnerabilidades, los profesionales consideran que tienen una gran relevancia y que su impacto futuro será mayor. Tanto en número de ataques como, sobre todo, en lo que respecta a su gravedad, como consecuencia del auge de los servicios Cloud y la complejidad de las arquitecturas.

Actuar sobre la capa de red y la de aplicación

Para prevenir este tipo de riesgos de seguridad, los desarrolladores deben poner en marcha controles de defensa en las capas de red y de aplicación. En lo que respecta a la primera se puede:

• Segmentar el acceso a recursos remotos en redes separadas.
• Aplicar políticas de cortafuegos de denegación por defecto o reglas de control de acceso para bloquear el tráfico de la intranet que no sea esencial.

Mientras que en lo relativo a la capa de aplicación se debe:

• Sanear y validar los datos de entrada suministrados por el cliente.
• Hacer cumplir el esquema, puerto y el dominio con una lista blanca de valores permitidos.
• Impedir el envío de respuestas a los clientes sin un previo tratamiento de la información.
• Desactivar las redirecciones HTTP.
• Garantizar la consistencia de la URL para evitar ataques.

En definitiva, el Top 10 de vulnerabilidades en aplicaciones web de OWASP, se ha convertido en un estándar de uso cotidiano en el desarrollo web. Un ranking que sistematiza y categoriza los principales riesgos en materia de seguridad. Una guía para profesionales de todo el mundo. Un trabajo minucioso cuyo objetivo es contribuir a que las aplicaciones web que empleamos sean más seguras. Y estén preparadas para hacer frente a ataques maliciosos.