El OWASP TOP 10 es una iniciativa de la organización sin ánimo de lucro Open Web Application Security Project (OWASP) que tiene como objetivo identificar y difundir las 10 vulnerabilidades de seguridad más críticas que afectan a las aplicaciones web. El OWASP TOP10 se basa en el análisis de datos de cientos de organizaciones y miles de vulnerabilidades reportadas por expertos en ciberseguridad de todo el mundo.
El propósito del OWASP TOP 10 es concienciar a los desarrolladores, administradores, auditores y usuarios sobre la importancia de aplicar medidas de seguridad en el diseño, desarrollo, implementación y mantenimiento de las aplicaciones web.
Los 10 principales riesgos de seguridad del OWASP Top 10 de 2021 (última actualización) son:
- Control de acceso roto
- Fallo criptográficos
- Inyección
- Diseño inseguro
- Configuración de seguridad incorrecta
- Fallos de identificación y autentificación
- Fallos de software e integridad de datos
- Fallos de registro y seguimiento
- Ataques de Falsificación de Peticiones del Lado del Servidor (SSRF)
Vamos a explicar de forma resumida cada una de estas vulnerabilidades, cómo se pueden explotar y cómo se pueden prevenir.
1. Control de acceso roto
La pérdida de control de acceso ocurre cuando un usuario no autorizado puede acceder a recursos o funcionalidades que no le corresponden. Por ejemplo, si un usuario puede ver o modificar los datos de otro usuario, o si puede acceder a páginas o acciones restringidas.
Para probar esta vulnerabilidad, se puede intentar cambiar el identificador de usuario en la URL, en las cookies o en los parámetros ocultos de los formularios. También se puede usar un proxy para interceptar y modificar las peticiones HTTP.
Un ataque muy conocido dentro de esta vulnerabilidad es:
¿Falsificación de petición en sitios cruzados (CSRF)?
La falsificación de petición en sitios cruzados (CSRF) es una técnica que consiste en inducir al usuario a realizar una acción no deseada en una aplicación web en la que está autenticado. De esta forma, el atacante puede aprovecharse de la confianza que la aplicación web tiene en el usuario y realizar operaciones como transferir dinero, cambiar contraseñas, enviar mensajes, etc.
Un ejemplo típico de CSRF es cuando un atacante envía un correo electrónico al usuario con un enlace o una imagen que contiene una petición maliciosa a la aplicación web.
Por ejemplo, si la aplicación web permite al usuario cambiar su contraseña mediante una petición GET como https://example.com/change_password?old=1234&new=4321, el atacante puede enviar un correo electrónico al usuario con una imagen como <img src=»https://example.com/change_password?old=1234&new=4321» width=»0″ height=»0″>. Esto hará que cuando el usuario abra el correo electrónico, se realice la petición GET y se cambie su contraseña sin su consentimiento.
Para prevenir el CSRF, se recomienda utilizar tokens o códigos aleatorios y únicos que se incluyan en las peticiones y se verifiquen en el servidor. También se debe evitar el uso de peticiones GET para realizar acciones sensibles, utilizar cabeceras HTTP que impidan el envío automático de cookies o sesiones y aplicar políticas de origen cruzado (CORS).
2. Fallos criptográficos
Esta vulnerabilidad abarca todos los datos que podrían quedar expuestos sin protección ni cifrado y que poseen un valor significativo para la entidad o individuo propietario de los mismos. Algunos ejemplos incluyen datos bancarios, información personal, credenciales de usuarios, contraseñas o bases de datos.
Por ejemplo, si vamos a Google y en el campo de búsqueda ingresamos la siguiente consulta:
intext:DB_PASSWORD || intext:"MySQL hostname" ext:txt
Conseguiremos que el motor de búsqueda de Google encuentre archivos con extensión .txt que contengan cadenas de texto “DB_PASSWORD” o “MySQL hostname”.
El aspecto clave aquí es aplicar esta técnica en nuestras pruebas de penetración y filtrar para que únicamente nos liste los resultados de nuestra página web.
Para prevenir los ataques de fallos criptográficos es recomendado utilizar protección al servidor web, lo que se conoce como “hardening”.
Esto implica:
- Configuraciones seguras: Ajustes para desactivar servicios no esenciales.
- Actualizaciones y parches: Mantener el sistema actualizado con las últimas correcciones de seguridad.
- Políticas de contraseñas seguras: Establecer contraseñas robustas y cambiarlas regularmente.
- Gestión de accesos y permisos: Limitar el acceso y privilegios a personas autorizadas.
- Cifrado de datos: Proteger información sensible mediante cifrado.
- Auditorías y monitorización: Registrar y revisar actividades para detectar posibles intrusiones.
3. Inyección
Los ataques de inyección ocurren cuando se envían peticiones a un intérprete de código en un formulario, campo editable o url. Los ataques de inyección más conocidos son:
Ataques de inyección SQL
La inyección de SQL es una técnica que consiste en introducir código malicioso en las consultas que se realizan a una base de datos desde una aplicación web. De esta forma, el atacante puede obtener información privada, modificar o eliminar datos, ejecutar comandos arbitrarios o acceder al sistema.
Un ejemplo típico de inyección de código SQL es cuando un atacante introduce un carácter especial como una comilla simple (‘) en un campo de entrada que espera un valor numérico o alfanumérico.
Por ejemplo, si la aplicación web espera recibir un identificador de usuario como 1234, el atacante puede introducir algo como 1234′ OR 1=1 –.
Esto hará que la consulta SQL resultante sea algo como SELECT * FROM users WHERE id = 1234′ OR 1=1 –, lo que devolverá todos los registros de la tabla users, ya que la condición 1=1 siempre se cumple. El carácter — indica el inicio de un comentario, por lo que el resto de la consulta se ignora.
Para prevenir la inyección de código SQL, se recomienda utilizar consultas parametrizadas, que separan la estructura de la consulta del valor de los parámetros. De esta forma, se evita que el código malicioso se interprete como parte de la consulta. También se debe validar y filtrar la entrada del usuario, restringir los permisos de acceso a la base de datos y cifrar los datos sensibles.
Cross-Site Scripting (XSS)
El Cross-Site Scripting (XSS) es una técnica que consiste en inyectar código JavaScript malicioso en una página web que se muestra al usuario. De esta forma, el atacante puede ejecutar acciones en nombre del usuario, robar sus cookies o sesiones, modificar el contenido o el aspecto de la página, redirigirlo a sitios maliciosos o instalar malware.
Un ejemplo típico de XSS es cuando un atacante introduce un código JavaScript en un campo de entrada que espera un texto plano.
Por ejemplo, si la aplicación web permite al usuario introducir su nombre para mostrarlo en un panel de administración, el atacante puede introducir algo como <script>alert(‘XSS’)</script>.
Esto hará que cuando el usuario vea la página con el panel del usuario, se ejecute el código JavaScript y se muestre una alerta con el texto ‘XSS’.
Para prevenir el XSS, se recomienda escapar o codificar los caracteres especiales que puedan ser interpretados como código HTML o JavaScript, como < > » ‘ & /.
También se debe validar y filtrar la entrada del usuario, utilizar cabeceras HTTP que impidan la ejecución de scripts externos o inline y aplicar políticas de seguridad del contenido (CSP).
4. Diseño inseguro
Las vulnerabilidades de diseño inseguro se presentan cuando los desarrolladores, equipos de calidad y/o de seguridad no logran anticipar y evaluar las amenazas durante la fase de diseño del código. Estas vulnerabilidades también son resultado de no seguir las prácticas adecuadas de seguridad durante el diseño de una aplicación. A medida que evolucionan las amenazas, mitigar estas vulnerabilidades requiere un modelado constante del código para prevenir métodos de ataque conocidos.
5. Configuración de seguridad incorrecta
La configuración de seguridad incorrecta se refiere a errores o descuidos en la configuración de los componentes del sistema, como el servidor web, el framework, la base de datos, etc. Estos errores pueden facilitar el acceso a los atacantes o exponer información sensible.
Para probar esta vulnerabilidad, se puede revisar la configuración del servidor web, como los permisos de los archivos, los encabezados HTTP, los mensajes de error, etc. También se puede buscar información sobre las versiones y las vulnerabilidades conocidas de los componentes utilizados.
Un ataque muy conocido dentro de esta vulnerabilidad es:
Exposición de entidades externas XML (XXE)
Esta vulnerabilidad ocurre cuando una aplicación web acepta y procesa documentos XML sin validar su contenido o su origen. Un atacante puede aprovechar esta debilidad para enviar documentos XML maliciosos que contengan referencias a entidades externas, como archivos, servicios o redes. De esta forma, el atacante puede acceder a información confidencial, ejecutar código remoto o provocar una denegación de servicio.
Para probar si una aplicación web es vulnerable a XXE, se puede enviar un documento XML que contenga una entidad externa que apunte a un recurso controlado por el atacante, como un servidor web o un archivo local. Si la aplicación web devuelve el contenido del recurso o muestra un error relacionado con él, significa que es vulnerable a XXE.
Para prevenir esta vulnerabilidad, se recomienda:
- Deshabilitar el procesamiento de entidades externas en los parsers XML que se utilicen.
- Utilizar formatos alternativos a XML, como JSON, siempre que sea posible.
6. Componentes con vulnerabilidades conocidas
Los componentes con vulnerabilidades conocidas son aquellos que la aplicación usa y que tienen fallos de seguridad documentados y publicados. Estos componentes pueden ser librerías, frameworks, plugins, etc.
Para probar esta vulnerabilidad, se pueden identificar los componentes que usa la aplicación y buscar información sobre sus versiones y sus vulnerabilidades conocidas. También se pueden usar herramientas automáticas que escanean la aplicación y detectan estos componentes.
7. Fallos de identificación y autenticación
El almacenamiento y transmisión inseguros de datos sensibles se produce cuando los datos que requieren protección, como contraseñas, tarjetas de crédito, información personal, etc., no se cifran adecuadamente o se almacenan en lugares inseguros.
Para probar esta vulnerabilidad, se puede verificar si la aplicación usa HTTPS para transmitir los datos sensibles y si implementa mecanismos de cifrado robustos. También se puede analizar el código fuente o la base de datos para ver cómo se almacenan los datos sensibles.
Esta categoría aborda debilidades en la autenticación y la gestión de sesiones que son cruciales para prevenir ataques relacionados con la autenticación. Las debilidades pueden surgir si la aplicación permite ataques automatizados, contraseñas débiles o su reutilización, almacenamiento inseguro de contraseñas, exposición de identificadores de sesión en la URL y falta de autenticación multifactor.
8. Fallos de software e integridad de datos
Los fallos de software e integridad de datos, también conocido como deserialización insegura. La deserialización insegura ocurre cuando la aplicación recibe datos en un formato serializado (como JSON, XML, etc.) y los convierte a objetos sin validarlos o filtrarlos. Esto puede permitir a un atacante ejecutar código arbitrario o modificar el comportamiento de la aplicación.
Para probar esta vulnerabilidad, se puede manipular los datos serializados que envía la aplicación y observar si se produce algún cambio o error. También se pueden usar herramientas específicas para generar cargas maliciosas que exploten esta vulnerabilidad.
9. Fallos de registro y seguimiento
Esta vulnerabilidad ocurre cuando una aplicación web no registra ni monitoriza adecuadamente las actividades que se realizan en ella, como las peticiones, las respuestas, las acciones de los usuarios o los errores. Esto dificulta la detección y la respuesta ante posibles ataques o incidentes de seguridad, así como el análisis forense posterior.
Para probar si una aplicación web tiene un registro e inspección insuficientes, se puede intentar realizar acciones maliciosas o anómalas en ella, como inyecciones SQL, ataques de fuerza bruta o accesos no autorizados. Si la aplicación web no genera ningún registro ni alerta sobre estas acciones, significa que tiene un registro e inspección insuficientes.
Para prevenir esta vulnerabilidad, se recomienda:
- Implementar un sistema de registro y auditoría que capture toda la información relevante sobre las actividades que se realizan en la aplicación web, como los datos de entrada y salida, los identificadores de sesión, las direcciones IP o los códigos de estado.
- Implementar un sistema de monitorización y alerta que analice los registros generados y detecte posibles anomalías o indicadores de ataque, como patrones sospechosos, errores frecuentes o valores inesperados.
10. Ataques de falsificación de peticiones del lado del servidor (SSRF)
Un Ataque de Falsificación de Peticiones del Lado del Servidor (SSRF, por sus siglas en inglés: Server-Side Request Forgery) es una vulnerabilidad de seguridad en aplicaciones web que permite a un atacante enviar solicitudes desde el servidor hacia otros recursos o servicios internos o externos a la red. Este tipo de ataque puede tener consecuencias graves, ya que puede permitir al atacante acceder a recursos internos no autorizados.
En un SSRF, el atacante manipula una aplicación web para que haga solicitudes HTTP a servidores específicos de su elección. Estas solicitudes se originan desde el servidor en lugar del navegador del usuario, lo que puede evadir las restricciones de seguridad que normalmente se aplicarían si fueran solicitudes del lado del cliente.
Para un análisis más técnico y profundo del OWASP Top 10, consulta el informe oficial y si quieres aprender a fondo estas vulnerabilidades conocidas, sígueme en mi canal de YouTube
Un comentario
Gracias por la info. Muy útil y explicada de manera muy sencilla.