En este artículo hablaremos de las 10 vulnerabilidades más importantes en el listado de OWASP hecho en el 2017. Aquí aparecen las vulnerabilidades más serias de aplicaciones Web, como nos podremos proteger de ellas y dejaré algunos enlaces para lo que quieran profundizar en el tema, tengan toda la información disponible.

OWASP (acrónimo de Open Web Application Security Project, en inglés “Proyecto abierto de seguridad de aplicaciones web) es un proyecto de código bierto dedicado a determinar y combatir las causas que hacen que el software sea inseguro. La fundación OWASP es un organismo sin ánimo de lucro que apoya y gestiona proyectos e infraestructura del OWASP. La comunidad está formada por empresas, organizaciones educativas, y particulares por todo el mundo.

OWASP no está afiliado a ninguna compañía tecnológica, si bien apoya el uso informado de tecnologías de seguridad. Ellos recomiendan enfocar la seguridad de aplicaciones informáticas considerando todas sus dimensiones: personas, procesos y tecnologías.

Seguridad no es un evento único. Es insuficiente programar de manera segura sólo una vez, hay que estar pendiente de los cambios producidos en el sector y las vulnerabilidades encontradas. En 2020, este Top 10 habrá cambiado, y si los programadores no están alertas de estas vulnerabilidades y no cambias ninguna línea de código, tu aplicación podría estar en peligro.

Un programa es seguro por diseño, durante el desarrollo es donde que hay que abordar todas las etapas del ciclo de vida del programa. Existen al menos 300 problemas que afectan a la seguridad general de una aplicación web. Lo que debemos es usar esta guía como referencia y no como un estándar sin antes revisar bien tu código.

Las credenciales de cuentas y los testigos de sesión (session token) frecuentemente no son protegidos adecuadamente. Los atacantes obtienen contraseñas, claves, o testigos de sesión para obtener identidades de otros usuarios.

Contramedidas: Usar autenticación de doble factor.

Los atacantes pueden obtener o modificar datos sensibles si no son seguramente tratados por la aplicación. Algunos ejemplos pueden ser el uso de claves no seguras o con cifrado TLS versión 1.0. Al usar cifrado por ejemplo en base 64 es más facil de ser decodifcado una vez que es capturada la transacción. Burpsuite puede ser la erramienta para interceptar el mensaje y decodificarlo sin problemas.

Una aplicación es vulnerable a ataques XXE si tiene habilitada la posibilidad el usuario subir ficheros XML, pudiendo ser maliciosos con lo que consecuentemente puede vulnerar el código y otras dependencia. Esto puede ser usado para ejecutar código malicioso, robar información y ejectuar tareas maliciosas.

La rotura del control de acceso ocurre cuando el usuario puede acceder a recursos que le están autorizados. Así el usuario puede acceder a páginas, bases de datos, directorios, etc. Aplicaciones que tienen diferentes tipos de cuentas como pueden ser administrador, operadores, auditores, etc. Uno de los problemas comunes es que los desarrolladores restringen los privilegios solo en la zona de UI y no en la zona del servidor. Si es explotado, cada usuario puede tener permisos de administrador.

Desarrolladores y personal de IT aseguran la funcionalidad de la aplicación pero no la seguridad. Las configuraciones son desarrolladas y aplicadas en el servidor, en la base de datos del servidor, proxy, aplicaciones y otros dispositivos tienen que estar alineados con los requerimientos de seguridad.

La mayoría de los requerimientos de seguridad son olvidados a no ser que sean identificados por expertos en ciberseguridad. Algunos ejemplos de una mala configuración serían: contraseñas poco seguras, contraseñas dejadas por defecto, script por defecto almacenados en los servidores, directorios por defecto y mensajes de error por defecto

Las fallas de XSS ocurren cuando una aplicación toma información originada por un usuario y la envía a un navegador Web sin primero validar o codificar el contenido. XSS permite a los atacantes ejecutar secuencias de comandos en el navegador Web de la víctima que pueden secuestrar sesiones de usuario, modificar sitios Web, insertar contenido hostil, etc.

Algunas aplicaciones graban información en el lado del cliente y ellos quizás usen la serialización del objeto. Aplicaciones que dependen del cliente para mantener el estado pueden que tenga el riesgo de que su serialización de la información sea modificada. Ejemplo: Alterando cookies puedes llegar a causar escalación de privilegios en usuario normal a adminsitrador

X: x :{ z: z:”NAME”: r:”USER”} –>> Normal cookie
X: x :{ z: z:”NAME”: r:”ADMIN”} –>> Altered cookie object

Si uno de los componentes con conocidas vulnerabilidades es usado por la aplicación puede llevar a brechas de seguridad. Estos componentes pueden ser frameworks codificados, librerias, funciones vulnerables, frameworks de red,etc.

Ejemplos: Uso de una versión de PHP vulnerable, usar un kernel que esté antiquado y un windows sin aplicar los parches de seguridad.

Ataques siguen pasando y eso que podemos poner inmenso número de contra-medidas y solo nos damos cuenta una vez que el sistema o aplicación ha sido infectado. A veces no somos capaces de detectar los ataques que han comprometido el sistema tiempo atrás y que ahora se han vuelto persistentes.

Para saber de antemano si el sistema ha sido vulnerado necesitaremos un sistema de registro de actividades (log) en el que podamos detectar el comportamiento anómalos de algunos usuarios conectados a la aplicación

Este documento puede usarse como ayuda y para identificar la severidad de las vulnerabilidades detectadas en nuestro sistema y hacerlo de una manera más afectiva. Además de estas vulnerabilidades yo también destacaría algunas que suelen suceder constantemente como:

• Clickjacking
• Buffer overflow
• API´s no seguras

¿Y tú?¿Tienes tus aplicaciones web protegidas?