Top 10 de Vulnerabilidades en aplicaciones web

Las aplicaciones web están más expuestas a que accedan personas de todo tipo y de cualquier lugar del mundo. La mayoría, harán un uso esperado de la aplicación o de la web. Pero una pequeña parte, intentará hacer el mal. Ya sea rompiendo la aplicación o accediendo a datos sensibles. A veces, simplemente quieren llevar tráfico a su web o colocar un enlace sin que te enteres.

De vez en cuando, seguro que oirás noticias de hackers que han accedido a los datos de los usuarios de grandes plataformas. Es verdad que, si tienes una aplicación con pocos usuarios, no será muy atractiva para atacantes y reducirá las posibilidades de ser atacado. Pero no hay que perder de vista el escenario de un posible ataque y tomar medidas para que fracase si se diera el caso.

Así, que hay que tomar un mínimo de precauciones para evitar sustos. Si el contenido fuera sensible, como información médica, habría que poner especial atención en estos temas.

De algunas se puede encargar el servidor, pero otras deben ser resueltas desde el código fuente y la programación.

Riesgos de seguridad en aplicaciones web

Vamos a ver los principales riesgos de seguridad en las aplicaciones web según OWASP.

1. Injection

Los riesgos de inyección, como la inyección SQL, NoSQL, OS y LDAP, se producen cuando se envían datos maliciosos 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 datos sin la debida autorización.

En SQL-Injection, por ejemplo, si la sentencia no está correctamente formada en el código del servidor, podrías dejar una puerta abierta para lanzar otras sentencias además de la esperada. Entre otras cosas, se podría lograr acceso a la base de datos, borrar tablas o extraer información sensible como los datos de los usuarios.

La mayoría de lenguajes de programación incorporan frameworks o instrucciones para evitar estos ataques. Pero sobre todo, habrá que seguir las buenas prácticas de cada lenguaje.

2. Broken Authentication

Las funciones de las aplicaciones relacionadas con la autenticación y la gestión de sesiones se implementan a menudo de forma incorrecta, lo que permite a los atacantes comprometer las contraseñas, las claves o los tokens de sesión. O incluso, aprovechar otros fallos de implementación para asumir las identidades de otros usuarios de forma temporal o permanente.

De esta forma pueden adquirir los permisos de estos usuarios. Ya te puede imaginar que es especialmente sensible si se pueden hacer con el control de un usuario o token de un administrador.

3. Sensitive Data Exposure

Muchas aplicaciones web y API no protegen adecuadamente los datos sensibles, como los financieros, los sanitarios y la información personal. Los atacantes pueden robar o modificar estos datos débilmente protegidos para llevar a cabo fraudes con tarjetas de crédito, robos de identidad u otros delitos. Los datos sensibles pueden verse comprometidos sin una protección adicional, como el cifrado en reposo o en tránsito, y requieren precauciones especiales cuando se intercambian con el navegador.

Aquí ayuda mucho el certificado SSL, para que toda la información viaje cifrada y sea más difícil de interceptar.

4. XML External Entities (XXE)

Muchos procesadores XML antiguos o mal configurados evalúan las referencias a entidades externas dentro de los documentos XML. Las entidades externas pueden utilizarse para revelar archivos internos utilizando el manejador de URI de archivos, acciones de archivos internos, escaneo de puertos internos, ejecución remota de código y ataques de denegación de servicio.

Existen dos tipos de ataques XXE:

  • XXE In-Band: Creación de una entidad accediendo a la URI y devolviendo el contenido en la respuesta.
  • XXE Out-Of-Band: Creación de una entidad accediendo a la URI y exfiltrando estos datos externamente, ya sea por DNS, FTP, HTTP, etc.

5. Broken Access Control

El Control de acceso roto consiste en que las restricciones sobre lo que pueden hacer los usuarios autentificados a menudo no se aplica correctamente. Los atacantes pueden aprovechar estos fallos para acceder a funcionalidades y/o datos no autorizados, como acceder a las cuentas de otros usuarios, ver archivos sensibles, modificar los datos de otros usuarios, cambiar los derechos de acceso, etc.

Así que es importante que el sistema de roles funcione correctamente y debería ser un punto imprescindible a la hora de realizar los tests y las pruebas del software.

6. Falta de configuración

La falta de configuración de la seguridad es el problema más frecuente. Esto es comúnmente el resultado de configuraciones inseguras por defecto, configuraciones incompletas o ad hoc, almacenamiento abierto en la nube, cabeceras HTTP mal configuradas y mensajes de error verbales que contienen información sensible.

No solo deben configurarse de forma segura todos los sistemas operativos, marcos de trabajo, bibliotecas y aplicaciones, sino que deben ser parcheados/actualizados de forma oportuna.

Esto, quizás, no sea una labor del desarrollador de software sino del ingeniero de sistemas que se encarga del servidor. Pero, en proyectos pequeños, puede que sea la misma persona la que se encargue de estas configuraciones, así que hay que tenerlas en cuenta más allá del propio código de la aplicación.

7. Cross-Site Scripting XSS

Los fallos XSS se producen siempre que una aplicación incluye datos no fiables en una nueva página web sin la validación o el escape adecuados, o actualiza una página web existente con datos suministrados por el usuario mediante una API del navegador que puede crear HTML o JavaScript.

El XSS permite a los atacantes ejecutar scripts en el navegador de la víctima que pueden secuestrar las sesiones del usuario, desfigurar los sitios web o redirigir al usuario a sitios maliciosos.

Hay tres tipos principales de ataques XSS:

  • XSS reflejado: el script malicioso proviene de la petición HTTP actual.
  • XSS almacenado: el script malicioso proviene de la base de datos del sitio web.
  • XSS basado en el DOM: la vulnerabilidad existe en el código del lado del cliente en lugar del código del lado del servidor.

Para evitarlo, se puede realizar varias acciones como filtrar las entradas, codificar los datos al mostrarlos usando las entidades HTML entre otras, o mediante las cabeceras HTTP Content-Type y X-Content-Type-Options.

8. Deserialización insegura

Al recuperar información de la base de datos al cliente, si la deserialización de esta información es insegura, podría modificarse en vivo para otorgarse permisos. Si, por ejemplo, detectas un atributo en esta información que decide si un usuario es administrador. Lo podrías modificar para que tu propio usuario pase a ser administrador.

La deserialización insegura a menudo conduce a la ejecución remota de código. Incluso si los defectos de deserialización no dan lugar a la ejecución remota de código, pueden ser utilizados para realizar ataques, incluyendo ataques de repetición, ataques de inyección y ataques de escalada de privilegios.

9. Uso de componentes con vulnerabilidades conocidas

Los componentes, como las bibliotecas, los frameworks y otros módulos de software, se ejecutan con los mismos privilegios que la aplicación. Si se explota un componente vulnerable, un ataque de este tipo puede facilitar la pérdida grave de datos o la toma de posesión del servidor.

Las librerías y API suelen publicar las vulnerabilidades conocidas y resueltas en las últimas versiones. Así que si alguien detecta que estás usando una versión muy antigua de algún componente, podría consultar sus vulnerabilidades y atacarlas.

Por ello es importante utilizar siempre que sea posible las últimas versiones y parches de cada uno de los componentes.

10. Registro y monitorización insuficientes

El registro y la supervisión insuficientes, junto con la falta o la ineficacia de la integración con la respuesta a incidentes, permite a los atacantes seguir atacando los sistemas, mantener la persistencia, pivotar a más sistemas y manipular, extraer o destruir datos.

Puede que nuestro sistema sea seguro, pero nos despistemos a la hora de comunicarnos con otros servidores y demos por hecho que también son seguros. O de otras aplicaciones con las cuales compartamos el servidor, base de datos o sistema de ficheros.

La mayoría de los estudios sobre infracciones muestran que el tiempo para detectar una infracción es de más de 200 días, normalmente detectada por partes externas en lugar de procesos internos o de supervisión.

Deja un comentario

Información sobre protección de datos

Vicente SG te informa que los datos de carácter personal que me proporciones rellenando el presente formulario serán tratados por Vicente Sancho Guijarro (Vicente SG) como responsable de esta web. La finalidad de la recogida y tratamiento de los datos personales que te solicito es para gestionar los comentarios que realizas en este blog. Legitimación: Consentimiento del interesado. Como usuario e interesado te informo que los datos que me facilitas estarán ubicados en los servidores de Banahosting.com (proveedor de hosting de Vicente SG) dentro de la UE. Ver política de privacidad de Banahosting.com. El hecho de que no introduzcas los datos de carácter personal que aparecen en el formulario como obligatorios podrá tener como consecuencia que no atender pueda tu solicitud. Podrás ejercer tus derechos de acceso, rectificación, limitación y suprimir los datos en [email protected] así como el derecho a presentar una reclamación ante una autoridad de control. Puedes consultar la información adicional y detallada sobre Protección de Datos en mi página web: https://vicentesg.com, así como consultar mi política de privacidad.