Los 10 principales riesgos de seguridad en aplicaciones web

Cada año, el Proyecto de código abierto de seguridad de aplicaciones web (OWASP) presenta un documento que contiene los 10 principales riesgos de seguridad. Este documento se creó para crear conciencia sobre la seguridad de las aplicaciones web y es especialmente útil para los desarrolladores. Representa un amplio consenso sobre los riesgos de seguridad más críticos para las aplicaciones web.

Parte de tu trabajo como desarrollador es ser consciente de los riesgos de seguridad que podrían amenazar una de tus aplicaciones. Ser consciente de estas amenazas es un buen primer paso.

¡Conocerlos y saber cómo puedes evitarlos es crucial para el proceso de mitigación de riesgos de seguridad! Entonces, sin más preámbulos, pasemos directamente a los 10 principales riesgos de seguridad.

Principales riesgos de aplicaciones web

1. Inyecciones

Las inyecciones no deberían ser nada nuevo para ti como desarrollador. Probablemente todos hemos escuchado sobre las cosas malas que pueden suceder cuando existe una vulnerabilidad de inyección dentro de tu aplicación.

Hay muchos tipos diferentes de vulnerabilidades de inyección, como inyección SQL, NoSQL, OS y LDAP. Una inyección puede ocurrir cuando se envían datos no confiables a un intérprete como parte de un comando o consulta.

Los datos hostiles del atacante pueden engañar al intérprete para que ejecute comandos no deseados o acceda a los datos sin la autorización adecuada. Esto a menudo es causado por datos proporcionados por el usuario que no son validados, filtrados o limpiados por la aplicación.

Puede parecer obvio para la mayoría de ustedes, pero tu aplicación no debe basarse únicamente en la validación front-end. Asegúrate de validar siempre tu lado del servidor de datos. Siempre. La validación de front-end es fácil de manejar (por ejemplo, cuando un usuario tiene JavaScript deshabilitado).

2. Autenticación vulnerada

Resulta que muchos de los riesgos de seguridad son causados ​​por la autenticación vulnerada. Esto tiene que ver principalmente con una implementación incorrecta. Las funciones de la aplicación relacionadas con la autenticación y la gestión de sesiones a menudo se implementan incorrectamente.

Esto permite a los atacantes comprometer contraseñas, claves o tokens de sesión, o explotar otras vulnerabilidades de implementación. Esto para asumir las identidades de otros usuarios de manera temporal o permanente.

Y todo eso es porque una parte de código no funcionó según lo previsto.

Sin embargo, hay algunas medidas que podrías tomar. Siempre que sea posible, debes implementar la autenticación de múltiples factores para evitar el relleno automatizado de credenciales. Asimismo, evitar la fuerza bruta y los ataques de reutilización de credenciales robadas.

Además de eso, podrías implementar una verificación de contraseña débil. Las contraseñas que ingresa el usuario no deben estar en la lista de las peores contraseñas.

Además, no debes enviar ni implementar ninguna credencial predeterminada, especialmente para usuarios administradores. Esto puede parecer obvio, pero sucede con demasiada frecuencia.

3. Exposición de datos sensibles

Muchas aplicaciones web y API no protegen adecuadamente los datos confidenciales, como los datos financieros y de atención médica. Los atacantes pueden robar o modificar dichos datos débilmente protegidos para realizar fraudes con tarjetas de crédito, robo de identidad u otros delitos.

Los datos confidenciales pueden verse comprometidos sin protección adicional y requieren precauciones especiales cuando se intercambian con el navegador.

Si deseas saber si tu aplicación es vulnerable, deseas saber cómo se transmiten los datos. ¿Se transmiten datos en texto plano? Esto se refiere a protocolos como HTTP, SMTP y FTP. También debes asegurarte de que no se utilicen algoritmos de cifrado antiguos o débiles, ya que son fáciles de descifrar.

Probablemente una de las mejores formas de evitar que los datos confidenciales estén expuestos es asegurándote de cifrar todos los datos confidenciales en reposo.

4. Entidades externas XML

Las entidades externas XML (XXE) son un tipo de ataque contra una aplicación que analiza la entrada XML. Muchos procesadores XML antiguos o mal configurados evalúan referencias de entidades externas dentro de documentos XML.

Las entidades externas se pueden usar para revelar archivos internos utilizando el controlador de URI de archivo y recursos compartidos de archivos internos. También, escaneo de puertos internos, ejecución remota de código y ataques de denegación de servicio.

La mayoría de las vulnerabilidades XXE existen porque la aplicación acepta XML directamente o cargas XML, especialmente de fuentes no confiables. O también si inserta datos no confiables en documentos XML, que luego es analizado por un procesador XML.

5. Control de acceso vulnerado

Las restricciones sobre lo que los usuarios autenticados pueden hacer a menudo no se aplican de manera adecuada. La mayoría de las veces, los usuarios tienen demasiados permisos, lo que es un problema.

Los atacantes pueden explotar estas fallas para acceder a datos o funciones no autorizadas. Por ejemplo, el acceso a las cuentas de otros usuarios, ver archivos confidenciales, modificar los datos de otros usuarios y cambiar los derechos de acceso.

Aquí hay una regla general muy buena que podrías usar como desarrollador: con la excepción de los recursos públicos, denegar el acceso de forma predeterminada. Es mejor prevenir que lamentar. Además de eso, puedes registrar errores de control de acceso e incluso alertar a los administradores cuando se producen demasiados errores de control de acceso.

6. Configuración incorrecta de seguridad

La configuración incorrecta de seguridad es el problema más comúnmente visto. Esto suele ser el resultado de configuraciones predeterminadas inseguras, configuraciones incompletas o ad hoc. Asimismo, encabezados HTTP mal configurados y mensajes de error detallados que contienen información confidencial.

No solo todos los sistemas operativos, frameworks, bibliotecas y aplicaciones deben estar configurados de manera segura, sino que deben actualizarse de manera oportuna.

Para minimizar las posibilidades de una mala configuración de seguridad, debes evitar instalar o habilitar funciones innecesarias. Además, evita los rastros de conjuntos u otros mensajes de error demasiado informativos para los usuarios que pueden revelarse mediante el manejo de errores. Y, por supuesto, cambiar las cuentas predeterminadas y tus contraseñas.

7.Cross-Site Scripting

Las secuencias de comandos entre sitios (XSS) son una de las vulnerabilidades más populares en la web hoy en día. Las vulnerabilidades de XSS ocurren cada vez que una aplicación incluye datos no confiables en una nueva página web sin una validación o escape adecuados. También cuando una página web existente se actualiza con datos proporcionados por el usuario utilizando una API de navegador que puede crear HTML o JavaScript. XSS permite a los atacantes ejecutar scripts en el navegador de la víctima que pueden secuestrar sesiones de usuario, desfigurar sitios web o redirigir al usuario a sitios maliciosos.

Para evitar que tu sitio web sea vulnerable a los ataques XSS, puedes usar un framework que escape automáticamente de XSS por diseño, como React. Y siempre es una buena idea escapar de los datos de solicitud HTTP no confiables en función del contexto en la salida HTML.

8. Deserialización insegura

Explotar la deserialización puede ser difícil de lograr. Esto se debe a que los exploits estándar rara vez funcionan sin cambios o ajustes en el código de exploits subyacente.

Sin embargo, los riesgos son muy altos. La deserialización insegura a menudo conduce a la ejecución remota de código. Incluso si las fallas de deserialización no resultan en la ejecución remota de código, pueden usarse para realizar ataques, incluidos ataques de repetición. Tambien, ataques de inyección y ataques de escalada de privilegios.

Hay algunas cosas que puedes hacer para evitar la deserialización insegura. Una de las cosas que podría hacer es implementar una verificación de integridad, como las firmas digitales en cualquier objeto serializado. Esto evita la creación de objetos hostiles o la manipulación de datos.

Otra cosa que podrías hacer es imponer limitaciones de tipo estrictas durante la deserialización antes de la creación de objetos. Ten en cuenta que se han demostrado evasiones a esta técnica, por lo que no es recomendable confiar únicamente en esto.

También podrías aislar y ejecutar código que se deserializa en entornos de bajos privilegios si es posible. Si eso no es posible, siempre puedes registrar excepciones y fallas de deserialización, como cuando el tipo entrante no es el tipo esperado.

9. Uso de componentes con vulnerabilidades conocidas

Este riesgo de seguridad me molesta mucho. Algunos desarrolladores tienden a usar componentes con vulnerabilidades conocidas solo para que su código funcione. Los componentes en este contexto significan bibliotecas, framework y otros módulos de software.

Todos ellos se ejecutan con los mismos privilegios que la aplicación. Si se explota un componente vulnerable, dicho ataque puede facilitar la pérdida grave de datos o tomar el control del servidor. Las aplicaciones y API que usan componentes con vulnerabilidades conocidas pueden debilitar las defensas de las aplicaciones y permitir varios ataques e impactos.

Para minimizar este riesgo, debes eliminar las dependencias no utilizadas, las características innecesarias y los archivos. Además, debes monitorear todos tus componentes regularmente para verificar si hay vulnerabilidades conocidas. Una forma sencilla de hacerlo es suscribiéndote a boletines de seguridad.

10. Insuficiente registro y monitoreo

El registro y monitoreo insuficientes, junto con la integración faltante o ineficaz con la respuesta a incidentes, permite a los atacantes atacar aún más los sistemas. Esto puede tener enormes consecuencias. Los atacantes podrían alterar, extraer o destruir datos. O posiblemente podrían pivotar a más sistemas.

Dato sorprendente: la mayoría de los estudios de incumplimientos de seguridad muestran que el tiempo para detectar un incumplimiento supera los 200 días. Por si fuera poco, generalmente lo detectan partes externas en lugar de procesos internos o monitoreo.