Las 3 principales vulnerabilidades de seguridad en aplicaciones web en 2024

Hemos identificado las 3 principales vulnerabilidades críticas de seguridad en aplicaciones web a las que se enfrentan los usuarios de Aikido. Esta guía describe qué son, por qué son tan comunes y cómo solucionarlas, junto con otras vulnerabilidades de riesgo destacadas que no pudimos ignorar.

Aborda estos problemas de forma temprana y eficaz, y ya estarás muy por delante en la lucha por mantener tu aplicación web segura contra el cibercrimen.

1. La vulnerabilidad de código más común y crítica (SAST)

Las Pruebas de seguridad de aplicaciones estáticas (SAST) son un método de prueba que escanea el código fuente en busca de vulnerabilidades en las primeras etapas del ciclo de desarrollo. Se denomina método de caja blanca porque el funcionamiento de la aplicación es conocido por el probador.

Ataques de inyección NoSQL (vulnerabilidad de código: SAST)

La inyección NoSQL puede provocar la filtración de datos, bases de datos corruptas e incluso el compromiso total del sistema. Lamentablemente, es una vulnerabilidad crítica de seguridad en aplicaciones web y hemos visto muchas cuentas de usuario de Aikido expuestas a ella.

¿Qué es la inyección NoSQL?

La inyección NoSQL es un tipo de ataque en el que los hackers utilizan código malicioso para manipular u obtener acceso no autorizado a una base de datos NoSQL. A diferencia de las inyecciones SQL, que se dirigen a bases de datos SQL, las inyecciones NoSQL explotan vulnerabilidades en bases de datos NoSQL como MongoDB. Puede provocar fugas de datos, corrupción o incluso el control total de la base de datos.

¿Por qué es tan común esta vulnerabilidad?

La inyección NoSQL es común en parte debido a la creciente popularidad de las bases de datos NoSQL, especialmente MongoDB. Estas bases de datos ofrecen beneficios de rendimiento, pero conllevan desafíos de seguridad únicos.

Además, las bases de datos NoSQL son flexibles, ya que aceptan varios formatos como XML y JSON. Esta flexibilidad es excelente, pero puede dar lugar a vulnerabilidades de seguridad en aplicaciones web, ya que las comprobaciones de seguridad estándar podrían no detectar entradas maliciosas adaptadas a estos formatos.

Y la amplia gama de bases de datos NoSQL, cada una con su propia sintaxis y estructura, también dificulta la creación de salvaguardas universales. Los profesionales de la seguridad deben comprender los detalles específicos de cada base de datos y eso añade complejidad al proceso de prevención.

Peor aún, y a diferencia de las inyecciones SQL tradicionales, las inyecciones NoSQL pueden ocurrir en diferentes partes de una aplicación. Esto las hace aún más difíciles de detectar.

¿Cómo puedes solucionar fácilmente esta vulnerabilidad?

Utiliza la validación de entradas y consultas parametrizadas. La validación de entradas asegura que los datos de usuario coincidan con los tipos y formatos esperados, rechazando valores inseguros. Las consultas parametrizadas evitan la incrustación de entradas no validadas.

En general, implementa siempre características de seguridad de bases de datos como la autenticación y el cifrado. Mantente actualizado con los últimos parches. Y asegúrate de realizar auditorías regulares de código y configuraciones para identificar y corregir esta y otras vulnerabilidades.

Mención honorífica: Dejar funciones de depuración peligrosas en el código (vulnerabilidad de código: SAST)

Las funciones de depuración expuestas permiten el reconocimiento que ayuda a los atacantes a explotar sistemas, a veces con un riesgo de seguridad significativo.

¿Qué son las funciones de depuración peligrosas?

Las funciones de depuración como phpinfo() pueden exponer información sensible sobre tu servidor y entorno. Esto incluye la versión de PHP, detalles del sistema operativo, información del servidor e incluso variables de entorno que podrían contener claves secretas (¡aunque definitivamente no recomendamos colocar claves secretas allí en primer lugar!).

Como resultado, detectar la estructura de su sistema de archivos a través de estas funciones de depuración podría permitir a los hackers llevar a cabo ataques de directory traversal si su sitio es vulnerable. Exponer phpinfo() por sí solo no es necesariamente un riesgo alto, pero puede facilitar ligeramente la tarea a los atacantes. El principio es claro: cuanta menos información específica tengan los hackers sobre su sistema, mejor.

¿Por qué es tan común esta vulnerabilidad?

Esta vulnerabilidad de seguridad en aplicaciones web a menudo ocurre porque los desarrolladores utilizan estas funciones para la depuración y, a veces, incluso las envían a producción para la resolución de problemas. Las entregas apresuradas, la falta de revisión de código y la subestimación de los riesgos contribuyen a que estas funciones queden expuestas.

¿Cómo puedes solucionar fácilmente esta vulnerabilidad?

• Revisión de código: verifica tu código regularmente para identificar y eliminar funciones de depuración antes de desplegar a producción.
• Herramientas de análisis de vulnerabilidades automatizado: utiliza una herramienta, como Aikido, que pueda detectar funciones de depuración peligrosas.
• Configuraciones específicas del entorno: asegúrese de deshabilitar las funciones de depuración en el entorno de producción.

2. La vulnerabilidad DAST más común y crítica

Las Pruebas de seguridad de aplicaciones dinámicas (DAST) son una técnica de prueba que identifica vulnerabilidades en aplicaciones en ejecución. Se denomina método de caja negra porque se centra únicamente en el comportamiento observable. DAST te muestra cómo podría ver el sistema un atacante.

Olvidar cabeceras de seguridad importantes: HSTS y CSP (vulnerabilidad en la nube: DAST)

Una falta de implementación adecuada de HSTS y CSP deja las aplicaciones web vulnerables a ataques importantes como XSS y la divulgación de información.

¿Qué es CSP?

Content Security Policy (CSP) es un mecanismo de seguridad que ayuda a combatir diversos ataques basados en navegador, como el cross-site scripting y el clickjacking. Lo hace restringiendo comportamientos de riesgo en páginas web, como JavaScript en línea y funciones eval() inseguras. CSP aplica valores predeterminados más seguros para mantener la integridad y confidencialidad del contenido. El beneficio clave es la protección contra la inyección maliciosa de scripts.

¿Por qué es tan común esta vulnerabilidad DAST?

Es muy común descuidar HSTS y CSP, especialmente CSP, y los desarrolladores a menudo priorizan la funcionalidad sobre estas cabeceras.

Deberías planificar CSP al principio del desarrollo, pero a menudo se pasa por alto. Y cuando los desarrolladores intentan implementarlo o adaptarlo más tarde, causa conflictos, por lo que omiten CSP por completo para seguir con otros trabajos. Esto deja las aplicaciones desprotegidas y sujetas a una serie de vulnerabilidades de seguridad en aplicaciones web.

¿Cómo puedes solucionar fácilmente esta vulnerabilidad DAST?

• Implementa HSTS para forzar conexiones solo HTTPS. Habilítalo en el servidor mediante archivos de configuración o un WAF.
• Define y aplica una CSP estricta y adaptada a tu aplicación, restringiendo prácticas inseguras como los scripts en línea. Prueba cuidadosamente la compatibilidad.
• Monitoriza y actualiza continuamente los encabezados a medida que la aplicación evoluciona para mantener la protección.

3. La vulnerabilidad en la nube más común y crítica (CSPM)

Las herramientas de Gestión de la Postura de Seguridad en la Nube (CSPM) monitorizan continuamente los entornos basados en la nube para asegurar el cumplimiento de los estándares de seguridad y las mejores prácticas. Las herramientas CSPM buscan configuraciones de seguridad incorrectas y están destinadas a mitigar riesgos.

Dejar los roles de IAM de EC2 vulnerables a ataques SSRF (nube: CSPM)

Los roles IAM de EC2 abiertos con frecuencia pueden permitir a los atacantes moverse lateralmente y obtener acceso no autorizado en entornos de nube. El impacto potencial de este tipo de ataque puede ser devastador.

¿Qué son los roles de IAM de EC2?

Los roles de IAM (Identity and Access Management) de EC2 en Amazon Web Services (AWS) delegan permisos para determinar las acciones permitidas sobre recursos específicos. Permiten que las instancias EC2 interactúen de forma segura con otros servicios de AWS sin necesidad de almacenar credenciales directamente en las propias instancias.

¿Qué es un ataque SSRF?

Un ataque de Server Side Request Forgery (SSRF) es cuando un atacante fuerza al servidor a realizar solicitudes a recursos internos como si fuera el propio servidor quien las hiciera. De esta manera, el atacante puede acceder potencialmente a sistemas no autorizados, eludir controles o incluso ejecutar comandos. Descubra este aterrador ejemplo de cómo un ataque SSRF tomó el control de la nube de una startup a través de un simple formulario para enviar un correo electrónico.

¿Por qué es tan común esta vulnerabilidad CSPM?

Los roles de IAM de EC2 suelen ser vulnerables a ataques SSRF debido a configuraciones de seguridad erróneas o roles con permisos excesivos. Gestionar permisos complejos en la nube es difícil y algunos desarrolladores pueden no comprender completamente los riesgos. Además, el deseo de que los servicios funcionen sin problemas a menudo puede llevar a los equipos a conceder más acceso del realmente necesario.

¿Cómo puedes solucionar fácilmente esta vulnerabilidad CSPM?

Hay formas sólidas de abordar los roles de EC2 y mitigar las vulnerabilidades de seguridad en aplicaciones web de SSRF. En primer lugar, cíñete al principio de mínimo privilegio: solo permite el acceso exacto que sea absolutamente necesario y nada más. Los roles excesivamente permisivos son una fuente de problemas.

A continuación, utiliza herramientas integradas de AWS como los grupos de seguridad y las ACL de red para restringir el tráfico y reducir las posibles vías de ataque SSRF. Cuanto más puedas limitar el acceso, mejor.

También es importante revisar y auditar los roles regularmente para detectar cualquier acceso innecesario que pueda ir apareciendo con el tiempo a medida que las cosas cambian. Mantente al tanto.

Y por último, implementa herramientas de seguridad de AWS centradas específicamente en detectar y prevenir ataques SSRF antes de que causen daño. Cuantas más capas de protección, más seguro estarás.

Segundo puesto: Runtimes de lambda en la nube obsoletos (nube: CSPM)

Cuando estos entornos de ejecución quedan obsoletos, pueden exponer las funciones lambda a los atacantes.

¿Qué son los runtimes de Lambda obsoletos?

Los runtimes de lambda obsoletos se refieren al uso de versiones anteriores de lenguajes de programación o entornos en funciones sin servidor (lambdas). Estos runtimes obsoletos pueden carecer de los últimos parches de seguridad o actualizaciones de características, lo que podría exponer las aplicaciones a vulnerabilidades de seguridad web conocidas.

¿Por qué es tan común esta vulnerabilidad CSPM?

La vulnerabilidad a menudo surge de una mentalidad de 'configurar y olvidar'. Los desarrolladores pueden desplegar lambdas con un runtime específico y descuidar su actualización a medida que se lanzan nuevas versiones. También pueden cometer el error de asumir que los proveedores de la nube se encargan de todo el mantenimiento. Aunque AWS y Google Cloud Functions mantendrán los runtimes con parches menores del sistema operativo, no realizarán actualizaciones importantes de lenguaje. Además de todo esto, la complejidad de gestionar múltiples lambdas facilita que los runtimes obsoletos pasen desapercibidos y generen un riesgo adicional.

¿Cómo puedes solucionar fácilmente esta vulnerabilidad CSPM?

Puede mitigar el riesgo siguiendo tres reglas sencillas:

• Revise regularmente qué runtimes se utilizan y compruebe si hay actualizaciones.
• Actualiza a las últimas versiones compatibles con parches de seguridad.
• Utiliza herramientas de automatización para gestionar y actualizar runtimes siempre que sea posible.

Vulnerabilidades de seguridad de aplicaciones web y mejores prácticas

Comprender estas vulnerabilidades de seguridad de aplicaciones web es esencial para la seguridad del sistema, pero recuerda seguir las mejores prácticas de seguridad. Mantente al día, aplica las correcciones adecuadas y mantén una monitorización regular para mantener tu entorno seguro.

Escanee su entorno con Aikido ahora mismo para averiguar si está expuesto a alguna de estas vulnerabilidades.

Consulta Aikido’s 2024 SaaS CTO Security Checklist para obtener consejos concisos sobre más de 40 formas de mejorar la seguridad en tu personal, procesos, código, infraestructura y más.